[kbuild-devel] Re: [patch] config language dep_* enhancements
Peter Samuelson wrote: You're willing to potentially perturb 2.4? This stuff is trivial enough, and easy enough to test, that I think it could go in 2.4, yes. I think you're underestimating the Gordian knot that is the CML1 corpus. Obviously xconfig would need to be dealt with in sync with the others, which I'm not doing during the prototyping / idea-mongering stage. Fair enough. I'm pleased to see that you have preserved those semantics. There are many places in the corpus where a dep_* lists as a dependency a variable which is not defined until later, or is only defined in some architectures, or is never defined. Earlier today I tweaked up gcml2 to detect them and found 260 in 2.5.29. You give me too much credit. The main motivation for dropping the '$' was to make possible the == n semantics. That the patch failed to do so was accident, not design. Ah, well that's more disturbing. Changing the existing semantics, regardless of how broken we all agree they are, is asking for a world of trouble. To pick an example, in 2.5.29 drivers/ide/Config.in:17 is dep_tristate 'SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works in make config and make allyesconfig precisely because of the semantic that you wish to change. In fact this is the first one gcml2 finds, I don't particularly feel like trawling through the other two hundred-odd. Some of them are harmless, I don't know how many. I know the current behavior is documented, but I had thought this was because changing the behavior was not feasible due to our Bash-based JIT parsers. Yes, changing the behaviour is infeasible with shell-based parsers. However, there is now a body of rules which implictly depend on the semantics. Can you provide a rationale for why the current behavior is desirable? I wouldn't call it desirable. I would use words like clunky, congealed, unorthogonal, riddled with errors, and very hard to fix like the rest of the config language. It seems to me that it only encourages buggy Config.in code (since == n in other contexts like the #defines), And != n in other contexts, like if [];then statements. Did I mention unorthogonal ? The problem is that logic in config language is implicitly four-state, with the null or empty value being a separate value distinct from y, m and n. The fact that both and n mean don't build this object to kbuild doesn't mean that and n are the same thing. This isn't really obvious. One example where there is a semantic difference between and n would be an autoconfigurator, where n would mean I have probed for this hardware and it is not present but means something like I have not probed. and I don't see any benefits other than that it's the status quo. I'm not defending the current syntax. It sucks and it's broken. But fixing it will break things that currently aren't broken (or more accurately are broken twice in opposite directions). If it's your intention to change the semantics of , perhaps it would be better to add new statements which feature the new syntax and new semantics *only* and have no backwards compatibility baggage. An example of this approach is the nchoice statement, which does the same thing as choice but with a more civilized syntax. + case $arg in + y|m|n) ;; + *) arg=$(eval echo \$$arg) ;; Don't you want to check at this point that arg starts with CONFIG_? Also, how about quoting \$$arg ? I suppose one could add sanity checks / diagnostics, but there are no other valid cases, so that's all they would be. Yes, but there are invalid cases, and surely you don't want to help to *increase* the amount of bugginess in the rules corpus? 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. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Mon, 12 Aug 2002, Greg Banks wrote: I'm pleased to see that you have preserved those semantics. There are many places in the corpus where a dep_* lists as a dependency a variable which is not defined until later, or is only defined in some architectures, or is never defined. Earlier today I tweaked up gcml2 to detect them and found 260 in 2.5.29. You give me too much credit. The main motivation for dropping the '$' was to make possible the == n semantics. That the patch failed to do so was accident, not design. Ah, well that's more disturbing. Changing the existing semantics, regardless of how broken we all agree they are, is asking for a world of trouble. To pick an example, in 2.5.29 drivers/ide/Config.in:17 is dep_tristate 'SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works in make config and make allyesconfig precisely because of the semantic that you wish to change. But so the change would be a good thing, right? It would make the behavior consistent between all configuration tools, CONFIG_BLK_DEV_IDESCSI would be not selectable in either. So people would have to notice that this statement is broken and fix it. I know the current behavior is documented, but I had thought this was because changing the behavior was not feasible due to our Bash-based JIT parsers. Yes, changing the behaviour is infeasible with shell-based parsers. However, there is now a body of rules which implictly depend on the semantics. If they do, they should be fixed. And, as I pointed out before, it is possible to fix even shell-based parsers. Can you provide a rationale for why the current behavior is desirable? I wouldn't call it desirable. I would use words like clunky, congealed, unorthogonal, riddled with errors, and very hard to fix like the rest of the config language. So you agree a bit of spring cleaning wouldn't hurt, right? ;) It seems to me that it only encourages buggy Config.in code (since == n in other contexts like the #defines), And != n in other contexts, like if [];then statements. Did I mention unorthogonal ? Well, you're right here. Which makes me think of my original idea as to define all CONFIG_* values to n unless they've explicitly been assign another value before. The problem is that logic in config language is implicitly four-state, with the null or empty value being a separate value distinct from y, m and n. The fact that both and n mean don't build this object to kbuild doesn't mean that and n are the same thing. This isn't really obvious. One example where there is a semantic difference between and n would be an autoconfigurator, where n would mean I have probed for this hardware and it is not present but means something like I have not probed. The main usage currently is make oldconfig, though .config may be a bit confusing: Questions which have been answered before (even with n) will not be asked again, whereas for undefined symbols, the corresponding question is put. So I think the logic should really be tristate, n,m,y, plus additionally a list of CONFIG_* values which have been defined (as opposed to just being n by default). This would get rid of the non-intuitive behavior of dep_* and allow simplifying all the if [ == n || == ] duplication. It's a bit cumbersome to implement in shell, but surely possible. Of course, this is a 2.5 change, though the only potential for breakage are the dep_* statements which are arguably already broken. It shouldn't be too hard to come up with a script which points out the dep_* statements which reference symbols defined only later (or use gcml2, which I understand can do that already?) to see how much breakage there may be. --Kai --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
[I wrote] This stuff is trivial enough, and easy enough to test, that I think it could go in 2.4, yes. [Greg Banks] I think you're underestimating the Gordian knot that is the CML1 corpus. Yes, very possibly. To pick an example, in 2.5.29 drivers/ide/Config.in:17 is dep_tristate 'SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works in make config and make allyesconfig precisely because of the semantic that you wish to change. Thank you! That's what I wanted to know. I had no idea there existed this class of bug (yes it's a bug). I don't know why I should be surprised, since the 17 architectures all have separately-maintained config.in files, most of which were written by porting gurus, not 'make config' gurus. That one example is more than enough to convince me *not* to try changing the ignore empty deps rule for 2.4. 2.5 is a different matter, though.. In fact this is the first one gcml2 finds, I don't particularly feel like trawling through the other two hundred-odd. Some of them are harmless, I don't know how many. This is like the Stanford checker stuff. These are bugs. You have the means to find them automatically, but not the time or desire to fix them. Post a list and perhaps others will pitch in. Something like drivers/ide/Config.in:17: In dep_tristate CONFIG_BLK_DEV_IDESCSI: drivers/ide/Config.in:17: CONFIG_SCSI not defined for i386, ppc, ... In this case the fix would be to move CONFIG_BLK_DEV_IDESCSI to the SCSI subsystem, where in my opinion it belonged anyway. This would break down if there are any actual cycles - things which can't logically be moved to a place after the definitions of the facilities on which they depend. That we have to worry about this at all is an artifact of using a procedural langauge, rather than a declarative language like Prolog or CML2. I *really* don't want to go *there*, though. (: And != n in other contexts, like if [];then statements. That is true. But that should not affect the dep_* logic, should it? The point here is that people who aren't hip-deep in config language code don't think about them being separate. Ergo bugs. If it's your intention to change the semantics of , perhaps it would be better to add new statements which feature the new syntax and new semantics *only* and have no backwards compatibility baggage. An example of this approach is the nchoice statement, which does the same thing as choice but with a more civilized syntax. I've been thinking hard about a new sort of 'if' statement that doesn't look like a test command. (Yes, it's my mission to eventually get rid of the '$'s in config language. I think it can be done, piecemeal, over a long period of time. This is if we don't end up adopting a whole new language like CML2 or Roman's stuff.) Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Mon, Aug 12, 2002 at 09:45:37PM +0200, Roman Zippel wrote: More examples of the cml1 limitations can be found in arch/ppc/config.in - a single choice statement needs to be splitted into multiple choice statements. Er, which are you referring to here? All of the choice statements are done for clarity here. :) Tho I was (and have been) pondering creating arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all of the options related to IBM 4xx processors to one file, Motorola 8xx to another, and general PPC's nicely. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Hi, On Mon, 12 Aug 2002, Tom Rini wrote: More examples of the cml1 limitations can be found in arch/ppc/config.in - a single choice statement needs to be splitted into multiple choice statements. Er, which are you referring to here? All of the choice statements are done for clarity here. :) Tho I was (and have been) pondering creating arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all of the options related to IBM 4xx processors to one file, Motorola 8xx to another, and general PPC's nicely. There is still a bit of overlap. Roughly it's possible to sort the machine types by cpu type, but IMO it's not the best solution. I think it would be better to sort them by general machine type. bye, Roman --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 12:13:51AM +0200, Roman Zippel wrote: Hi, On Mon, 12 Aug 2002, Tom Rini wrote: More examples of the cml1 limitations can be found in arch/ppc/config.in - a single choice statement needs to be splitted into multiple choice statements. Er, which are you referring to here? All of the choice statements are done for clarity here. :) Tho I was (and have been) pondering creating arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all of the options related to IBM 4xx processors to one file, Motorola 8xx to another, and general PPC's nicely. There is still a bit of overlap. Roughly it's possible to sort the machine types by cpu type, but IMO it's not the best solution. I think it would be better to sort them by general machine type. Er, 'general machine type' ? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
Hi, On Mon, 12 Aug 2002, Tom Rini wrote: There is still a bit of overlap. Roughly it's possible to sort the machine types by cpu type, but IMO it's not the best solution. I think it would be better to sort them by general machine type. Er, 'general machine type' ? +-RPX | +- ... +-TQM | +- ... +-Motorola | +- ... ... A bit more flexibility certainly wouldn't hurt. :) bye, Roman --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 12:32:50AM +0200, Roman Zippel wrote: Hi, On Mon, 12 Aug 2002, Tom Rini wrote: There is still a bit of overlap. Roughly it's possible to sort the machine types by cpu type, but IMO it's not the best solution. I think it would be better to sort them by general machine type. Er, 'general machine type' ? +-RPX | +- ... +-TQM | +- ... +-Motorola | +- ... ... A bit more flexibility certainly wouldn't hurt. :) What does that gain however? And it wouldn't make as much sense to offer the IBM Spruce (750) next to the IBM Walnut (405GP). So in short, the various choice menus in arch/ppc/config.in aren't to work around CML1 issues, it an intentional design (which really needs to become 4 files). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
Hi, On Mon, 12 Aug 2002, Tom Rini wrote: A bit more flexibility certainly wouldn't hurt. :) What does that gain however? And it wouldn't make as much sense to offer the IBM Spruce (750) next to the IBM Walnut (405GP). You weren't forced to sort them by cpu type. Maybe it works as is, you should know that better than me. I only used it as an example, because my tool has problems to automatically convert this construct into something useful (e.g. because of CONFIG_WILLOW in 2 seperate choice statements). bye, Roman --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 01:17:15AM +0200, Roman Zippel wrote: Hi, On Mon, 12 Aug 2002, Tom Rini wrote: A bit more flexibility certainly wouldn't hurt. :) What does that gain however? And it wouldn't make as much sense to offer the IBM Spruce (750) next to the IBM Walnut (405GP). You weren't forced to sort them by cpu type. Maybe it works as is, you should know that better than me. heh. It is something actually works pretty well, and with the rare exception of things which can show up twice (see below) it's rather logical too. I only used it as an example, because my tool has problems to automatically convert this construct into something useful (e.g. because of CONFIG_WILLOW in 2 seperate choice statements). That's because CONFIG_WILLOW can either have an 8260 CPU or a 7xx/74xx CPU. Or I think an ARM cpu... And unfortunatly I don't think support for anything beyond maybe 8260 is actually in the trees right now anyhow. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
[Roman Zippel] with the latest modifications this can be written as: dep_tristate NEW !OLD dep_tristate OLD !NEW This still has the back reference and you have to run 'make config' twice to change NEW from n to y. I don't see this as a big problem. Most people don't use the bare Configure script anyway, except for 'make oldconfig'. With the ! patch, Menuconfig does the right thing here. It's possible to fix this: tristate DRV if [ DRV == y ]; then choice OLD NEW fi if [ DRV == m ]; then dep_tristate NEW DRV dep_tristate OLD DRV fi Simpler and perhaps more intuitive: tristate DRV dep_mbool DRV_OLD DRV dep_mbool COMMON_OPT DRV dep_mbool OLD_OPT1 DRV_OLD dep_mbool OLD_OPT2 DRV_OLD dep_mbool NEW_OPT1 DRV !DRV_OLD dep_mbool NEW_OPT2 DRV !DRV_OLD I don't see a real need for a separate symbol announcing DRV_NEW. Let the Makefile cope. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Peter Samuelson wrote: [...]CONFIG_BLK_DEV_IDESCSI[...] That one example is more than enough to convince me *not* to try changing the ignore empty deps rule for 2.4. 2.5 is a different matter, though.. Ah, good. This is like the Stanford checker stuff. These are bugs. You have the means to find them automatically, but not the time or desire to fix them. Actually I have got the desire to fix them, what I lack is the ability to get patches into the kernel that are too non-trivial to go through Rusty. Post a list and perhaps others will pitch in. Something like drivers/ide/Config.in:17: In dep_tristate CONFIG_BLK_DEV_IDESCSI: drivers/ide/Config.in:17: CONFIG_SCSI not defined for i386, ppc, ... Ok, but perhaps it's not clear how many problems there are. The full log file from a gcml2 run on 2.5.29 is 573 KiB. Here's a summary: 977missing-experimental-tag 113spurious-experimental-tag 145variant-experimental-tag 30 inconsistent-experimental-tag 13 missing-obsolete-tag 41 spurious-obsolete-tag 25 variant-obsolete-tag 5 spurious-dependencies 187nonliteral-define 28 unset-statement (ignore these) 25 different-banner 61 different-parent 36 overlapping-definitions 1 primitive-in-root 310undeclared-symbol 73 forward-compared-to-n 287forward-reference 1093 forward-dependancy 1 symbol-like-literal 103constant-symbol-dependency 8 different-compound-type 3562 total These numbers are aggregates over 17 arches, so you need to divide by a number between 1 and 17. Also some of these have been fixed in 2.5.30. I can post the full list if people want, but it would be a bit overwhelming. In this case the fix would be to move CONFIG_BLK_DEV_IDESCSI to the SCSI subsystem, where in my opinion it belonged anyway. Ok then. This would break down if there are any actual cycles - things which can't logically be moved to a place after the definitions of the facilities on which they depend. I'm not able to detect anything like that. That we have to worry about this at all is an artifact of using a procedural langauge, rather than a declarative language like Prolog or CML2. Actually config language isn't really procedural, pseudo-procedural would be more like it. I *really* don't want to go *there*, though. (: Yep. And != n in other contexts, like if [];then statements. That is true. But that should not affect the dep_* logic, should it? Correct, I'm just pointing out that using orthogonality arguments with the config language is not going to get you anywhere useful. The point here is that people who aren't hip-deep in config language code don't think about them being separate. Ergo bugs. Agreed. I've been thinking hard about a new sort of 'if' statement that doesn't look like a test command. Interesting, I'd like to hear more. My favourite idea is a different form of choice which worked more like a menu, so you could intersperse conditionals with the choice items. This would help with the several places in CML1 were the same choice is mostly-duplicated in different conditionals, e.g. 'Kernel page size' in arch/ia64/config.in. ESR worked out a sensible set of semantics for how this should work. (Yes, it's my mission to eventually get rid of the '$'s in config language. I think it can be done, piecemeal, over a long period of time. Sounds good to me. This is if we don't end up adopting a whole new language like CML2 or Roman's stuff.) Or a new parser frontends for the existing language. I'm not convinced that a complete new language will ever succeed after the CML2 debacle, machine translated or not. This is why I gave up the idea of automatically converting CML1 to CML2. 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. --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: Most should be fixable. The biggest problem are recursive references like this: if [ OLD != y ]; then tristate NEW fi if [ NEW != y ]; then tristate OLD fi [...]It's possible to fix this: tristate DRV if [ DRV == y ]; then choice OLD NEW fi if [ DRV == m ]; then dep_tristate NEW DRV dep_tristate OLD DRV fi That should look interesting in xconfig, It will also give gcml2 conniptions trying to figure out a set of constraints which will enforce the intended behaviour. Please please don't. If there are any loops (and I don't know of any) then the logic is broken and needs to be fixed, not enforced through clever tricks. This should work quite well with config and menuconfig and maybe someone fixes xconfig, so a lot can be fixed within cml1, but it won't be necessarily nice. :) I didn't make up this example, just look at CONFIG_SCSI_AIC7XXX* which would need fixing like this. I will look, but I seem to remember that this code was just broken when Keith Owens was trying to make it work in kbuild 2.5. The current config is really very limited and can not be easily extended (just try adding the help text or build information). At some point we have to drop cml1 and replace it with something else. sighonce more into the breach... This doesn't has be very painful, I have a tool that can convert most of the current config into whatever you want. The problem is deciding what the original rules were supposed to mean, and then reproducing that behaviour exactly in the new language. The alternative is fixing the problems as we convert, but then we end up with CML2 and the there's no way to verify the rulebase is the same argument. 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. --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: I only used it as an example, because my tool has problems to automatically convert this construct into something useful (e.g. because of CONFIG_WILLOW in 2 seperate choice statements). You too? I had to rewrite my branch merging code to make CONFIG_WILLOW fit. 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. --- 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
[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
[kbuild-devel] Re: [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/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. --- 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
