Re: [patch] config language dep_* enhancements

Greg Banks (gnb@alphalink.com.au)
Tue, 13 Aug 2002 14:31:19 +1000


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/Config.in:22:forward 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/Config.in:38:forward 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.

Bizarre.

> 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/*/config.in 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/Config.in:40:CONFIG_ZORRO
13 sound/oss/Config.in:209:CONFIG_INPUT_GAMEPORT
11 drivers/parport/Config.in:14:CONFIG_SERIAL
10 drivers/media/video/Config.in:33:CONFIG_USB
6 drivers/video/Config.in:134:CONFIG_I2C
3 drivers/net/Config.in:324:CONFIG_CARDBUS
3 drivers/scsi/Config.in:264:CONFIG_PCMCIA
2 drivers/char/Config.in:193:CONFIG_PCMCIA
2 drivers/net/Config.in:327:CONFIG_PCMCIA
2 drivers/net/wireless/Config.in:27:CONFIG_PCMCIA
2 drivers/net/wireless/Config.in:41:CONFIG_PCMCIA
2 drivers/scsi/Config.in:116:CONFIG_PARPORT
1 arch/alpha/config.in:262:CONFIG_PROC_FS
1 arch/sh/config.in:298:CONFIG_MAPLE
1 drivers/ide/Config.in:26:CONFIG_PCI
1 drivers/parport/Config.in:27:CONFIG_PCMCIA

> 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.

Greg.

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/