Re: [PATCH][2.3.99-pre9] arch/i386/config.in PM xconfig bug

From: David Weinehall (tao@acc.umu.se)
Date: Wed May 24 2000 - 20:30:01 EST


On Wed, 24 May 2000, Andrzej Krzysztofowicz wrote:

>
> > in the General Setup Menu, if Power Management is N, xconfig offers the
> > suboptions of ACPI or APM. I identified the != "n" tests as problematic
> > (since CONFIG_APM/ACPI are undefined/empty) and wrapped the entire
> > section in a [ "$CONFIG_PM" != "n" ] to circumvent that problem.
> >
> > It my perception of the problem is correct, so is my patch. Is there
> > any CodingStyle as to the indention depth for config.in? My patch uses
> > 2 characters indent.
>
> Yes, xconfig does not like != "n" conditions in some cases.

Which is quite understandable; a lots of the limitations in xconfig are
due to the fact that they require rebuilding menus...

> Most of the newest config fixes use indentation of 3 spaces, however there
> is no documented CodingStyle in this matter.

Oh? Colour me insane, then. I know there is, because I wrote that very
part of the CodingStyle-document myself; hence the somewhat sucking
wording... Oh, and I made most of the changes to make the indentation
follow these rules too. I'm sad to say, people seem to ignore it quite
often. I'll have to submit some cleanups to Linus soon, I guess...

>From Documentation/CodingStyle:

<blockquote comment="I'm NOT using HTML-mail. This is manually inserted">

                Chapter 7: Configuration-files

For configuration options (arch/xxx/config.in, and all the Config.in
files), somewhat different indentation is used.

An indention level of 3 is used in the code, while the text in the config-
options should have an indention-level of 2 to indicate dependencies. The
latter only applies to bool/tristate options. For other options, just use
common sense. An example:

if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
   tristate 'Apply nitroglycerine inside the keyboard (DANGEROUS)'
CONFIG_BOOM
   if [ "$CONFIG_BOOM" != "n" ]; then
      bool ' Output nice messages when you explode' CONFIG_CHEER
   fi
fi

Generally, CONFIG_EXPERIMENTAL should surround all options not considered
stable. All options that are known to trash data (experimental write-
support for file-systems, for instance) should be denoted (DANGEROUS),
other Experimental options should be denoted (EXPERIMENTAL).

</blockquote>

[The rest of your mail + the patch snipped]

Regards: David Weinehall
  _ _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:13 EST