[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
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
