[lkml]   [2002]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] config language dep_* enhancements
Peter Samuelson wrote:
> [Greg Banks]
> > Ah, glad you asked, see attached output from the latest version of gcml2
> > (not yet released).
> Thank you thank you thank you! Exactly what I wanted!

Pleased to be of service ;-)

> Now, while some (perhaps a lot) of these instances will break with the
> proposed new semantics, many will not. Starting from the top:
> > =====alpha
> > warning:drivers/pcmcia/ declared symbol "CONFIG_ARCH_SA1100" used in dependency list for "CONFIG_PCMCIA_SA1100"
> In context:
> if [ "$CONFIG_ARM" = "y" ]; then
> dep_tristate ' SA1100 support' CONFIG_PCMCIA_SA1100 $CONFIG_ARCH_SA1100 $CONFIG_PCMCIA
> fi
> With the new semantics, there would be no need for the 'if' statement.
> CONFIG_ARCH_SA1100 is a sufficient guard, since non-ARM machines will
> never define it.

Agreed, the current form is a direct result of the current dep_tristate
semantics and would not be necessary with your proposed semantics.

> > warning:drivers/block/ declared symbol "CONFIG_SCSI" used in dependency list for "CONFIG_CISS_SCSI_TAPE"
> This one is legit. It's a weird case where a single driver can be
> built with or without using the SCSI subsystem - in effect, two
> drivers sharing a single piece of hardware and presenting two views of
> it.


> My preferred "fix" is to move the 'tristate CONFIG_SCSI' to early in
> the Block Devices menu. ATA should be under Block Devices too, come
> to think of it, and perhaps a generic guard for non-IDE-non-SCSI RAID
> cards. The actual menus could come later under toplevel, or be nested
> within "Block Devices".

Along these lines, CML2 had a menu 'buses' very early in the root of
the tree, containing queries for ISA, PCI, MCA, SERIAL, PARPORT,
HOTPLUG, IDE, SCSI, USB, IEEE1394 and FC4. I won't post the code
here because I can't fully understand it anymore :-(

> All in all, by asserting that 'n' == '', you can drop all the
> 'define_bool FOO n' from the arch/*/ files (like CONFIG_SBUS
> on i386 or CONFIG_PCI on s390), and you can drop a *lot* of guard 'if'
> statements. A few things would actually break, like not defining
> CONFIG_SCSI soon enough.

You will also probably want to deal with the cases where possibly null-valued
symbols are compared against "n" like this

if [ "$CONFIG_NOT_DECLARED" != "n" ]; then....

73 forward-compared-to-n
13 drivers/parport/
13 sound/oss/
11 drivers/parport/
10 drivers/media/video/
6 drivers/video/
3 drivers/net/
3 drivers/scsi/
2 drivers/char/
2 drivers/net/
2 drivers/net/wireless/
2 drivers/net/wireless/
2 drivers/scsi/
1 arch/alpha/
1 arch/sh/
1 drivers/ide/
1 drivers/parport/

> I think it's worth it. It will take some time to go through your 260
> unique warnings (984 total), of course.


> BTW - speaking of the length of your warnings list - what would be
> *really* nice would be a way to determine that a particular "forward
> declared symbol" is actually a "never-in-this-arch declared symbol".
> That would eliminate most of the false positives. If for example we
> can determine that we will never define CONFIG_ZORRO on this arch, we
> can safely assume that anything which depends on CONFIG_ZORRO *should*
> be suppressed.

Shouldn't be too hard, I'm already doing something like this to distinguish
between forward declared and undeclared symbols for the forward-reference
and undeclared-symbol warnings.

the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.192 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site