Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 12 Aug 2002 22:39:51 -0500 | Subject | Re: [patch] config language dep_* enhancements | From | Peter Samuelson <> |
| |
[Greg Banks] > Ah. If you're willing to knowingly feed Linus with patches that > break current config behaviour, then OK we have a way to proceed.
Things knowingly break in 2.5 all the time. I for one have no problem with this. Especially since the breakage is so easy to pinpoint, thanks to your script.
> I don't think there's any value to gratuitously breaking 2.4's > config. That's the point of a "stable" series right?
Correct. I for one have no intention of changing 2.4 semantics, except to expand them to allow '!' syntax, if I can finish that up.
> 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!
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.
The next 7 lines are similar, with CONFIG_PPC, CONFIG_MIPS and CONFIG_ARM as the guards.
> 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.
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".
> warning:drivers/ide/Config.in:21:forward declared symbol "CONFIG_SCSI" used in dependency list for "CONFIG_BLK_DEV_IDESCSI"
See above.
> warning:drivers/ide/Config.in:84:forward declared symbol "CONFIG_ARCH_ACORN" used in dependency list for "CONFIG_BLK_DEV_IDE_ICSIDE" > warning:drivers/ide/Config.in:88:forward declared symbol "CONFIG_ARCH_ACORN" used in dependency list for "CONFIG_BLK_DEV_IDE_RAPIDE" > warning:drivers/ide/Config.in:91:forward declared symbol "CONFIG_AMIGA" used in dependency list for "CONFIG_BLK_DEV_GAYLE" > warning:drivers/ide/Config.in:95:forward declared symbol "CONFIG_ZORRO" used in dependency list for "CONFIG_BLK_DEV_BUDDHA" > warning:drivers/ide/Config.in:98:forward declared symbol "CONFIG_ATARI" used in dependency list for "CONFIG_BLK_DEV_FALCON_IDE" > warning:drivers/ide/Config.in:101:forward declared symbol "CONFIG_MAC" used in dependency list for "CONFIG_BLK_DEV_MAC_IDE" > warning:drivers/ide/Config.in:104:forward declared symbol "CONFIG_Q40" used in dependency list for "CONFIG_BLK_DEV_Q40IDE" > warning:drivers/ide/Config.in:107:forward declared symbol "CONFIG_8xx" used in dependency list for "CONFIG_BLK_DEV_MPC8xx_IDE" > warning:drivers/net/Config.in:28:forward declared symbol "CONFIG_ARCH_EBSA110" used in dependency list for "CONFIG_ARM_AM79C961A" > warning:drivers/net/Config.in:34:forward declared symbol "CONFIG_ALL_PPC" used in dependency list for "CONFIG_MACE" > warning:drivers/net/Config.in:38:forward declared symbol "CONFIG_ALL_PPC" used in dependency list for "CONFIG_BMAC" > warning:drivers/net/Config.in:48:forward declared symbol "CONFIG_GSC_LASI" used in dependency list for "CONFIG_LASI_82596" > warning:drivers/net/Config.in:239:forward declared symbol "CONFIG_PPC_ISERIES" used in dependency list for "CONFIG_VETH"
All obviously tied to a specific arch. Most but not all are guarded by ARCH_* symbols, but that doesn't matter - with the new semantics they work with or without extra guards.
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.
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. (Modulo outright bugs where someone wrote $CONFIG_ZORRO for something that does not in fact require zorro.)
Peter - 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/
| ![\](/images/icornerr.gif) |