Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Sat, 24 Aug 2002, Greg Banks wrote: | Peter Samuelson wrote: | | [Randy.Dunlap] | Is there a script that checks for CONFIG_ variable dependency ordering | in [Cc]onfig.in files? If so, where can I get it? | |http://www.alphalink.com.au/~gnb/gcml2/ | | Thanks, Peter. Randy, the options you want to use are | -Wno-all -Wforward-dependency -Wundeclared-dependency Thanks. I'm trying it out now. BTW Greg, your checker web page spells 'dependency' as 'dependancy' in a few places. -- ~Randy --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Randy.Dunlap wrote: On Sat, 24 Aug 2002, Greg Banks wrote: | Peter Samuelson wrote: | |http://www.alphalink.com.au/~gnb/gcml2/ Thanks. I'm trying it out now. BTW Greg, your checker web page spells 'dependency' as 'dependancy' in a few places. Damn. It's a good thing I didn't need to use the words seperate or Ferrarri. 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ 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 Thu, 22 Aug 2002, Greg Banks wrote: Why do you want to do the parser/syntax switch separately? Why do you want to write and test a parser just to be throw it away again? So that the changes have some chance of getting past Linus. Sorry, but that's a dumb reason. Linus is quite capable to understand the reasons, if you explain them to him. Linus will likely not accept controversial changes. So said ESR. No, he said you have to configure your kernel like aunt Tillie, so you get laid. ;-) bye, Roman --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: Hi, On Thu, 22 Aug 2002, Greg Banks wrote: Why do you want to do the parser/syntax switch separately? Why do you want to write and test a parser just to be throw it away again? So that the changes have some chance of getting past Linus. Sorry, but that's a dumb reason. Linus is quite capable to understand the reasons, if you explain them to him. Linus will likely not accept controversial changes. Ok, perhaps I'm being over-cautious, but after seeing the reception that both CML2 and kbuild2.5 received I'm leery of doing anything other than strictly evolutionary (i.e. gradualist) changes. So said ESR. No, he said you have to configure your kernel like aunt Tillie, so you get laid. ;-) Followed by a 15-line signature about guns ;-) 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
[EMAIL PROTECTED] (Greg Banks) wrote on 19.08.02 in [EMAIL PROTECTED]: In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? As for the idea of a new parser, if we could define a parser interface that can be made to work with both menuconfig and xconfig (creating a working oldconfig and config seems rather trivial), then writing a common parser to support that interface, and testing it David's way, should not be too hard. Reading and writing .config, and parsing the various config.in and Configure.help files, shouldn't give any unsurmountable problems. But *can* we design such an interface? (And can we get people to port menuconfig and xconfig to those new interfaces?) Can we even agree on the requirements of such an interface? (And, incidentally, if we had that, then possibly we could put a parser for a different config language in which has the exact same interface, and thus can use the existing frontends, at some later date.) MfG Kai --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ 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 19, 2002 at 11:48:00PM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Greg Banks) wrote on 19.08.02 in [EMAIL PROTECTED]: In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? As for the idea of a new parser, if we could define a parser interface that can be made to work with both menuconfig and xconfig (creating a working oldconfig and config seems rather trivial), then writing a common parser to support that interface, and testing it David's way, should not be too hard. Reading and writing .config, and parsing the various config.in and Configure.help files, shouldn't give any unsurmountable problems. Something like mconfig? Just needs someone to write an X interface (and some more time for me to get 0.21 out of the door..). --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
[EMAIL PROTECTED] said: David suggest to use randomly generated configurations, but they lack one important feature. They are always valid, and a new system shall be able to deal with hand-edited .config files in the same way as oldconfig. I suggested those as a way for testing the equivalence of the old and new rulesets if the language changed. My main objection to CML2 was not the language itself or the gratuitous use of python, but the fact that the actual configuration rules were changed in extremely dubious ways. Think 'provably correct transforms between AndreCode and C'. You do also want to deal with hand-edited .config files in a similar manner to the existing tools, yes -- but that's a different issue. -- dwmw2 --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ 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 Wed, 21 Aug 2002, Greg Banks wrote: I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set by a choice statement and later redefined. My new parser can't deal with this, because user input is given the highest priority. Well then, there's something we need to look at fixing in the CML1 corpus. I considered detecting such cases, but it's too much work for something that is easy to find and fix manually. The alpha config.in is actually the only config file I could find that does something like this. bye, Roman --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: The problem here is one should consider, how all these little changes will help to solve the big problems. Do they allow to more easily fix the big problems or have these changes to be dumped again? I believe fixing the existing rules within the existing syntax is an exercise worth doing, and that the results will carry across to whatever extended syntax/ new language/new parsers/whatever will be the long-term solution. Extending the CML1 syntax now is a fun game but a gamble. Most of the suggestions I've seen so far fix problems, which either can be either fixed automatically or which don't exists anymore, once we switch to a new syntax/parser. That's the reason I ask to understand the whole picture, so we can judge whether a change is really necessary or not. Unlike you, I'm not optimistic that a switch to a new language or even a new parser for the old language will ever happen. I can't give you a mathematical proof, but I tried very hard to keep the behaviour the same. Unless I made mistake the rules are almost exactly the same. Most of the CML1 rules are usable, there are only very few cases which need manual fixing. I can't guarantee that where won't be any surprises, but they should be easily fixable in the new system. (Unless ESR I don't insist that my rulebase is correct or perfect, so I'm open to suggestion/changes. :) ) In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? Most of these problems can actually be fixed without syntax changes. Yes, a great deal of them can be, and those should be done ASAP. Something that can't be sanely fixed this way are recursive dependencies, which I think are not worth fixing with the old parsers, but which are easily fixable with the new syntax. Indeed, and those are rare corner cases. If you want to fix logical errors in the rulebase, they will be more easily fixable with the new tools. For the X interface I'm planning some debug options, which e.g. allow you to see the complete dependencies of every symbol. Or you could, today, go build gcml2 from source with make DEBUG=1 and run cml-check --debug nodes arch/i386/config.in 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ 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, 19 Aug 2002, Greg Banks wrote: Unlike you, I'm not optimistic that a switch to a new language or even a new parser for the old language will ever happen. It would be nice if I could get it into 2.6, but it's not a problem if it has to wait. I'm currently busy getting menuconfig working again and then I'm pretty much ready for a beta release. In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? If you compare it to the xconfig output, yes. Or you could, today, go build gcml2 from source with make DEBUG=1 and run I looked through the list and except from real syntax errors nothing prevents an automatic conversion. I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set by a choice statement and later redefined. My new parser can't deal with this, because user input is given the highest priority. bye, Roman --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ 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 19, 2002 at 07:27:50PM +1000, Greg Banks wrote: I'm not optimistic that a switch to a new language or even a new parser for the old language will ever happen. I asked Linus specifically about the replacement of the shell based parsers. The answer were quite simple: - It should be convinient to use a new parser. - Fast compilation, no errors etc. It's doable. In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? David suggest to use randomly generated configurations, but they lack one important feature. They are always valid, and a new system shall be able to deal with hand-edited .config files in the same way as oldconfig. Sam --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Hi, (Could you please fix your mailer? linux-m68k.org.com does not really exist.) On Thu, 15 Aug 2002, Greg Banks wrote: The problems are really not simple, the current config language is very limited, [...] I don't think anyone who actually understands the config system would argue these points, but we are limited by practical constraints to making incremental improvements only. That's fine with me, but nonetheless I'd really like to know where it will go to. Just fixing the easy problems is simple, but so far I haven't seen any plan on how to fix the hard problems. Anyone starting to fix all the problems should have at least some ideas how to do it and I'd really like to hear them. I don't want to discourage anyone, but he should understand the complete problem first before going for the easy targets. bye, Roman --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Thu, 15 Aug 2002, Roman Zippel wrote: I don't think anyone who actually understands the config system would argue these points, but we are limited by practical constraints to making incremental improvements only. That's fine with me, but nonetheless I'd really like to know where it will go to. Just fixing the easy problems is simple, but so far I haven't seen any plan on how to fix the hard problems. Anyone starting to fix all the problems should have at least some ideas how to do it and I'd really like to hear them. I don't want to discourage anyone, but he should understand the complete problem first before going for the easy targets. I think concentrating on the small gotchas for now is a good thing. Surely not all conceptual problems are fixable easily, they probably need to be done in conjunction with switching to a common parser etc. (Note: this switch to a new parser should happen with no change to the config.in format or semantics, in order to fit the Linux/Linus way of doing things). However, I think it is too late in 2.5 for these kind of big changes. That doesn't mean that fixing bugs, of which there are plenty, and small improvements like == n where possible shouldn't be done. If nothing else, it will at least give a better starting point for more elaborate work later. --Kai --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: Hi, (Could you please fix your mailer? linux-m68k.org.com does not really exist.) I believe the problem is upstream of the machine I control. I'll see what I can do. That's fine with me, but nonetheless I'd really like to know where it will go to. Just fixing the easy problems is simple, but so far I haven't seen any plan on how to fix the hard problems. Anyone starting to fix all the problems should have at least some ideas how to do it and I'd really like to hear them. I don't want to discourage anyone, but he should understand the complete problem first before going for the easy targets. The easy targets being done now are mostly things that I believe would need to be done regardless of the eventual strategy, be it a) do nothing b) make the existing system suck less c) replace the parsers and keep the rules d) replace everything. For any of these strategies to be successful you would need to start with a clean clear and consistent rules corpus. Remember how people were complaining that ESR couldn't prove that the CML2 rules corpus did the same things as the CML1 rules corpus? One of the reasons was that the CML1 rules corpus is so screwed that's its impossible for either a human or a machine to figure out what was supposed to happen and whether what was actually happening was deliberate. Roman, I believe the exactly same issue will apply to your config system too, because it uses a machine translation step from CML1. GCML2's syntax checker started life as a CML1-to-CML2 converter (inspired by your work), but I gave up on machine translating because it would be GIGO. This is why I'm not talking about replacing shell based parsers yet. First we need to get a rules corpus for which it is possible to create a parser which can parse cleanly, consistently, and correctly. 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: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
[John Alvord] I've been puzzling about this problem and the CML2 trainwreck. Maybe we can used advanced tools to remove the many bugs and inconsistancies and then switch to a better config tool. That's exactly what we're trying to do. Greg has the advanced consistency checking, and I've been trying to remove ambiguities and warts in the current rule corpus, and simultaneously come up with some extensions to the current language that will let us remove *more* warts. The extensions are designed to completely supplant certain existing constructs which I consider ugly and difficult to parse. To paraphrase Orwell: it was intended that when Newspeak had been adopted once and for all and Oldspeak forgotten, a buggy parser should be literally unimplementable, at least so far as implementation is dependent on clear syntax and reasonable semantics. Peter --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
Hi, On Tue, 13 Aug 2002, Peter Samuelson wrote: Mutating the language, long-term, so that it looks less like sh and more like a specialised language, is IMO a worthy goal. And I think it can be done. The main thing to deal with is adding an alternative syntax for 'if' statements which doesn't look like test(1). More about that in a separate message. That doesn't solve any of the more fundamental problems. 1) We still have 3 config parsers, which produce slightly different .config files. 2) To integrate a new driver, you have to touch at least 3 files: Config.in, Config.help, Makefile. Properly configuring and building a driver outside of the tree is painful to impossible. I'm not against fixing the bugs in the config scripts or adding some small extensions, but if you want to mutate the language into something different, I really hope you have a good plan for that. The problems are really not simple, the current config language is very limited, which also limits a bit the current error sources. As soon as you add new features, you need to add better error checking, which will be very painful in pure shell and keeping it consistent between multiple parsers will also be interesting. It's not the same problem area as with the build system. There we only have a single Rules.make file. Normal users don't need to care much about it. make was actually designed to build applications. The build system can rely on correct information from the config system. The build system was fixable within the capabilities of make, but the config system involves a lot more complex system of various scripts and programs. If you some great ideas to fix all the problems, I'd really like to hear them. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Peter Samuelson wrote: [Greg Banks] [...CONFIG_SERIAL and CONFIG_PCMCIA warnings...] Hmmm, either I missed those in your earlier messages, or you didn't post them. Probably I didn't post them. What I posted was a small subset of the full log. + dep_tristate ' I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C Are you sure want this one there? I didn't like it either, but it's needed in a couple odd places. What would you suggest - moving the whole i2c menu up? Not all the way up to the new menu, but before the bits that depend on them, which are in drivers/video/ drivers/media/video and drivers/ieee1394 IIRC. Thanks, your oracle feedback is much appreciated. I'm hoping to have an RPM out this weekend so you can do the augury yourself. @@ -210,2 +210,5 @@ 2 CONFIG_FB +2 CONFIG_KMOD +2 CONFIG_MODULES +2 CONFIG_MODVERSIONS 2 CONFIG_RTC What does that mean? All I did there was to combine two toplevel menus into one. Did this do something bad? Apparently. In the stock kernel: warning:arch/mips/config.in:224:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition warning:arch/parisc/config.in:53:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition Did I mention Gordian knot? -36 overlapping-definitions +38 overlapping-definitions 11 CONFIG_SOUND_CMPCI_FMIO @@ -261,2 +263,3 @@ 2 CONFIG_PARPORT +2 CONFIG_USB OK, I see CONFIG_USB in arch/cris/drivers/Config.in - is there another instance I'm missing? There's two in the same file, lines 185 and 189. -8 different-compound-type -3290 total +10 different-compound-type +3055 total different-compound-type? Please ignore that one. It's an artifact of the way I check for symbols not declared anywhere at all, related to config.in's using the same banner for a menu and a comment. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: Hi, On Tue, 13 Aug 2002, Peter Samuelson wrote: Mutating the language, long-term, so that it looks less like sh [...] That doesn't solve any of the more fundamental problems. Correct, it doesn't. 1) We still have 3 config parsers, which produce slightly different .config files. Yes. 2) To integrate a new driver, you have to touch at least 3 files: Config.in, Config.help, Makefile. Properly configuring and building a driver outside of the tree is painful to impossible. Yes. The problems are really not simple, the current config language is very limited, [...] I don't think anyone who actually understands the config system would argue these points, but we are limited by practical constraints to making incremental improvements only. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
[Greg Banks] + dep_tristate ' I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C Are you sure want this one there? I didn't like it either, but it's needed in a couple odd places. What would you suggest - moving the whole i2c menu up? Not all the way up to the new menu, but before the bits that depend on them, which are in drivers/video/ drivers/media/video and drivers/ieee1394 IIRC. It should be possible to take I2C back out of init/Config.in, in that case. I'll do that in my tree. +2 CONFIG_KMOD +2 CONFIG_MODULES +2 CONFIG_MODVERSIONS 2 CONFIG_RTC What does that mean? All I did there was to combine two toplevel menus into one. Did this do something bad? Apparently. In the stock kernel: warning:arch/mips/config.in:224:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition warning:arch/parisc/config.in:53:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition Weird. These should have triggered all along - any idea why they didn't? Well, they're fixed in my tree. It looks [trivial], but this one makes me uneasy. I mean, it's such an obvious bug - the toplevel Loadable module support menu appears twice - that I almost think it was somehow intentional. Did I mention Gordian knot? Yes, I believe you did. Does that make ESR Alexander the Great? (: OK, I see CONFIG_USB in arch/cris/drivers/Config.in - is there another instance I'm missing? There's two in the same file, lines 185 and 189. Right - they're mutually exclusive, so I thought it might only count as one. Anyway, fixed in my tree. related to config.in's using the same banner for a menu and a comment. mainmenu_option next_comment ... now *there's* a bit of syntax that needs to change. Even config-language.txt agrees. 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: [Greg Banks] +2 CONFIG_KMOD +2 CONFIG_MODULES +2 CONFIG_MODVERSIONS 2 CONFIG_RTC What does that mean? All I did there was to combine two toplevel menus into one. Did this do something bad? Apparently. In the stock kernel: warning:arch/mips/config.in:224:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition warning:arch/parisc/config.in:53:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition Weird. These should have triggered all along - any idea why they didn't? Because you moved the items to a menu with a different name. GCML2 issues the overlapping-definitions warning if the same item appears twice in such a way that both definitions can be visible at the same time. A sub-case is where the item appears twice unconditionally in the same menu, which was happening before your change. Another sub-case is where the item appears twice unconditionally in different menus, which happened after your change. Hence overlapping-definitions warnings for CONFIG_KMOD et al did not appear in the diff of summaries. GCML2 issues the different-parent warning when an item appears in two different menu parents, regardless of conditions. Before your change, the two identically named menus were merged into one node (this behaviour is very necessary for reasons too complex to go into here) so the two definitions of CONFIG_KMOD had the same parent. After your change, they had different parents, hence the new warnings. Well, they're fixed in my tree. It looks [trivial], but this one makes me uneasy. I mean, it's such an obvious bug - the toplevel Loadable module support menu appears twice - that I almost think it was somehow intentional. There are many [trivial] errors. My favourite is CONFIG_SOUND_CMPCI_FMIO. Did I mention Gordian knot? Yes, I believe you did. Does that make ESR Alexander the Great? (: Given the noise of his arrival and the speed of his departure...Darius. related to config.in's using the same banner for a menu and a comment. mainmenu_option next_comment ... now *there's* a bit of syntax that needs to change. Even config-language.txt agrees. That would be great, but the problem is related to the way comments are defined in CML2, which doesn't quite fit in CML1. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Thu, 15 Aug 2002 11:52:48 +1000, Greg Banks [EMAIL PROTECTED] wrote: Roman Zippel wrote: Hi, On Tue, 13 Aug 2002, Peter Samuelson wrote: Mutating the language, long-term, so that it looks less like sh [...] That doesn't solve any of the more fundamental problems. Correct, it doesn't. 1) We still have 3 config parsers, which produce slightly different .config files. Yes. 2) To integrate a new driver, you have to touch at least 3 files: Config.in, Config.help, Makefile. Properly configuring and building a driver outside of the tree is painful to impossible. Yes. The problems are really not simple, the current config language is very limited, [...] I don't think anyone who actually understands the config system would argue these points, but we are limited by practical constraints to making incremental improvements only. I've been puzzling about this problem and the CML2 trainwreck. Maybe we can used advanced tools to remove the many bugs and inconsistancies and then switch to a better config tool. That way the rulebase will be (almost) identical when the config process changes. john alvord --- 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_code1 ___ 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, Peter Samuelson wrote: 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 This way you can't compile old and new driver as module. 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
Hi, On Tue, 13 Aug 2002, Greg Banks wrote: 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. My only requirement is that the resulting rulebase is usable and roughly the same, some small bugs are IMO acceptable. CML2 has more problems than this. It's a very flexible but also very complex language, which makes it hard to use. It was also not very wise to create a complete new and different rulebase, which made it very hard to compare both. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Roman Zippel wrote: On Tue, 13 Aug 2002, Greg Banks wrote: 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. My only requirement is that the resulting rulebase is usable and roughly the same, some small bugs are IMO acceptable. http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 CML2 has more problems than this. Agreed. I was just pointing out that one of the many objections to CML2 would also apply to any new language which wasn't provably mappable from CML1. It's a very flexible but also very complex language, which makes it hard to use. It was also not very wise to create a complete new and different rulebase, which made it very hard to compare both. Nor was it wise to use Python, and less so to insist on a cutting edge version of Python, nor to throw away all the user interfaces, etc etc. And don't even get me started on pickling and freezing. Its very easy to be wise in hindsight; let's use that wisdom to do better this time. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Peter Samuelson wrote: [...] 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. Ok, here it is. 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. forward-deps2.txt.gz Description: GNU Zip compressed data
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote: 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 How about extending the language (side effect) to automagically append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent on those special tags? Sam --- 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
[Greg Banks]
Ok, here it is.
Thanks again. It will take some time to double-check what I termed
the false positives, but now you've reduced the interesting cases
down to 30 symbols.
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and lines for me.)
Here are the problem cases - things known to break with my proposed
'n'=='' - and my proposed solutions. I'll see if I can roll a patch
later today:
CONFIG_SCSI should be defined earlier, like in the Block Devices
menu. Then again, 'sg' is not a block device so this isn't strictly
correct. Perhaps a kernel subsystems submenu under general setup,
or even as a toplevel menu.
CONFIG_I2C and CONFIG_USB are also widely used outside their own
subtrees. They should probably go in with the kernel subsystems
menu along with CONFIG_SCSI.
CONFIG_PROC_FS is needed by ISDN hysdn. That's actually in my opinion
more of a general kernel facility than a filesystem. Eh?
Then again it could be said that requiring CONFIG_PROC_FS is actually
a design bug in hysdn - does the driver *really* need CONFIG_PROC_FS?
Everything else in the kernel seems to cope without it. Granted,
non-/proc kernels are not widely tested Kai?
CONFIG_ISDN_CAPI - interestingly, CONFIG_HYSDN_CAPI, which is under
the menu Old ISDN4Linux (obsolete) seems to require CAPI 2.0. I
suppose the CAPI stuff should come first in drivers/isdn/Config.in.
Kai?
CONFIG_SOUND_ACI_MIXER - the miroSOUND radio driver wants something
from OSS sound. Really I think sound/Config.in Sound Card Support
should be moved to a sub-menu of drivers/media/Config.in Multimedia
Devices.
CONFIG_INPUT - arch/{alpha,mips,mips64}/config.in are broken. There's
a comment in other arch/*/config.in files to the effect that
drivers/input/Config.in must come before drivers/usb/input/Config.in.
These 3 explicitly do the opposite.
CONFIG_SOUND_GAMEPORT - defined in drivers/input/gameport/, used only
in sound/oss/. I'm not sure what's going on here - why a separate
define (there is also CONFIG_GAMEPORT), and why do some sound cards
require its presence? Also I'm a bit suspicious of the logic in
drivers/input/gameport/ - it's either buggy, or way too clever.
This one is just confusing. Not sure what to recommend. I'll
probably have to stare at the Makefiles and the C for awhile to see
what's actually going on.
---
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
[Sam Ravnborg] How about extending the language (side effect) to automagically append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent on those special tags? I've thought about that too. Menuconfig already has magic code to append ' (NEW)' if it hasn't seen a symbol before. Your proposed change, however, cannot be easily parsed until we make '$' optional (and deprecated) in dep_* tags. The existing Configure and Menuconfig borrow the /bin/sh parser which, if allowed to see $CONFIG_EXPERIMENTAL, will expand it too early to be of use. 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
On Tue, 13 Aug 2002, Peter Samuelson wrote: CONFIG_PROC_FS is needed by ISDN hysdn. That's actually in my opinion more of a general kernel facility than a filesystem. Eh? Well, the use in hysdn can (and should) die, possibly by adding an #ifndef CONFIG_PROC_FS #error This driver won't work without procfs #endif until fixed properly. Then again it could be said that requiring CONFIG_PROC_FS is actually a design bug in hysdn - does the driver *really* need CONFIG_PROC_FS? Everything else in the kernel seems to cope without it. Granted, non-/proc kernels are not widely tested Kai? I don't know, I suspect it needs it for something like firmware loading or so. But since that's obviously an abuse of /proc, it's okay to have it break IMO. CONFIG_ISDN_CAPI - interestingly, CONFIG_HYSDN_CAPI, which is under the menu Old ISDN4Linux (obsolete) seems to require CAPI 2.0. I suppose the CAPI stuff should come first in drivers/isdn/Config.in. Kai? Yes. I'll look into that and fix it properly - I think just exchanging probably gives the same kind of problem for CONFIG_ISDN ;( --Kai --- 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
[Kai Germaschewski] Well, it'd be nice to first fix the dep_* statements so that they don't break when that change is done (i.e. in this case, moving IDESCSI behind CONFIG_SCSI. Yes. That's my current plan. Basically, extend the source command to do a grep CONFIG_* in the file to be read and set all found symbols to n, if unset - only then do the actual source. Ugly - I'd rather not have to do it that way. (: Anyway, some more points: o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs. b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR (the latter proposed by Peter Samuelson) I see the following: b) needs a large scale patch through all Config.in's. OTOH, it can be done step by step, only changing an instance after it has been looked at. a) means only a patch to Configure/menuconfig etc, but since it changes semantics, it'd be nice to check all possibly breaking usages (not too hard thanks to gcml2) sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case it is not hard to support both syntaxes - once the transition is complete, or reasonably complete, we can change the semantics to 'n'=='', which in Configure/Menuconfig can only be enforced in the non-$ case (well, unless we use your 'source' statement idea). I find a) more intuitive, for people who know sh, it's pretty clear when we use $ and when not. Also, for 'if' statements, we'll have to use the $ variant anyway for all I can see, so I prefer that from a consistency point of view. The problem with intuitive for people who know sh is that people think Config.in *is* shell. They start putting in constructs which are not valid Config.in syntax but which *are* valid sh syntax, so they work with certain parsers but not others. Mutating the language, long-term, so that it looks less like sh and more like a specialised language, is IMO a worthy goal. And I think it can be done. The main thing to deal with is adding an alternative syntax for 'if' statements which doesn't look like test(1). More about that in a separate message. a) has the advantage of automatically getting rid of the ugly duplicated 'if' tests: (And I think it should allow for getting rid of the quotation marks, too) if [ $CONFIG_FOO = -o $CONFIG_FOO = n ] -- if [ $CONFIG_FOO == n ] if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ] -- if [ $CONFIG_FOO != n ] See above - 'if' is due for an overhaul as well. o whatever we do, having a nice way to handle two exclusive drivers would be nice You mean the case where A=y implies B=n B=y implies A=n A=m implies B=m B=m implies A=m I agree. Not sure if it needs special casing or just better general facilities. I think it can be well served by the dep_* !CONFIG_FOO patch, where !y==n, !n==y, !==y, and !m==m. Then dep_tristate CONFIG_A !CONFIG_B dep_tristate CONFIG_B !CONFIG_A 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, 13 Aug 2002, Greg Banks wrote: Kai Germaschewski wrote: But so the change would be a good thing, right? It would make the behavior consistent between all configuration tools, Sorry, I don't understand what you're getting at. Currently the behaviour is consistent between config, menuconfig and xconfig: null-valued deps are ignored. For some reason, I thought that menuconfig or xconfig were handling the case differently. Apparently not, sorry about that. CONFIG_BLK_DEV_IDESCSI would be not selectable in either. So people would have to notice that this statement is broken and fix it. Ah. If you're willing to knowingly feed Linus with patches that break current config behaviour, then OK we have a way to proceed. Well, it'd be nice to first fix the dep_* statements so that they don't break when that change is done (i.e. in this case, moving IDESCSI behind CONFIG_SCSI. So you agree a bit of spring cleaning wouldn't hurt, right? ;) Absolutely, and I have a catalogue of dust puppies to help that process ;-) Okay. Let me first state that I do not really have the time to get involved currently. ISDN4Linux and other pending kbuild stuff already takes somewhat more than the remaining free time I have. But if you guys want to get going with some step by step cleaning (w/o breaking too much), I can try to help reviewing and submitting to Linus. 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. CML2's semantics were that all symbols have a default which is a zero; for booleans and tristates that means n. Changing from those semantics to the ones necessary to run the gcml2 rulebase on CML1 rules was one of the most painful parts of supporting CML1. So I think having an explicit n default is a good idea, but I fail to see how you would actually implement such a thing in a shell based parser. Basically, extend the source command to do a grep CONFIG_* in the file to be read and set all found symbols to n, if unset - only then do the actual source. 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 is precisely the CML2 semantics. Of course, this is a 2.5 change, Agreed. though the only potential for breakage are the dep_* statements which are arguably already broken. I don't think there's any value to gratuitously breaking 2.4's config. That's the point of a stable series right? I agree. Anyway, some more points: o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs. b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR (the latter proposed by Peter Samuelson) I see the following: b) needs a large scale patch through all Config.in's. OTOH, it can be done step by step, only changing an instance after it has been looked at. a) means only a patch to Configure/menuconfig etc, but since it changes semantics, it'd be nice to check all possibly breaking usages (not too hard thanks to gcml2) I find a) more intuitive, for people who know sh, it's pretty clear when we use $ and when not. Also, for 'if' statements, we'll have to use the $ variant anyway for all I can see, so I prefer that from a consistency point of view. b) is better if you want to add features like automatic (EXPERIMENTAL) a) has the advantage of automatically getting rid of the ugly duplicated 'if' tests: (And I think it should allow for getting rid of the quotation marks, too) if [ $CONFIG_FOO = -o $CONFIG_FOO = n ] -- if [ $CONFIG_FOO == n ] if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ] -- if [ $CONFIG_FOO != n ] o whatever we do, having a nice way to handle two exclusive drivers would be nice --Kai --- 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
Sam Ravnborg wrote: On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote: 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 How about extending the language (side effect) to automagically append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent on those special tags? Yes, this is obviously a good idea, and also it's what CML2 did. Especially considering that (NEW) is automatically generated, and (NEW) is not intuitively different from (EXPERIMENTAL) to the lay user. The trouble is actually achieving that in shell-based parsers where shell code cannot tell whether $CONFIG_EXPERIMENTAL has been used in a condition. 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
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
Kai Germaschewski wrote: So you agree a bit of spring cleaning wouldn't hurt, right? ;) Absolutely, and I have a catalogue of dust puppies to help that process ;-) Okay. Let me first state that I do not really have the time to get involved currently. ISDN4Linux and other pending kbuild stuff already takes somewhat more than the remaining free time I have. But if you guys want to get going with some step by step cleaning (w/o breaking too much), I can try to help reviewing and submitting to Linus. Great. Basically, extend the source command to do a grep CONFIG_* in the file to be read and set all found symbols to n, if unset - only then do the actual source. Ah, interesting idea. Anyway, some more points: o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs. b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR I assume you include in a) the change which gives all symbols an n default. Then b) is clearly the evolutionary approach and less likely to result in a partially broken config system come Halloween. 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
[I wrote] sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case it is not hard to support both syntaxes - once the transition is complete, [Greg Banks] Does complete mean all the ports have also made the change and been merged back? Either that, or, Linus gets tired of seeing mixed syntax in his tree, does the 'sed' himself, and removes the compatibility parsing. Linus has never been afraid to force the hand of a port maintainer. Remember what happened to the old-style Rules.make syntax just before 2.4 went gold. Actually I suspect it would be more like the C99 thing: after the new syntax is added, we start doing [TRIVIAL] patches to clean out the old, and eventually once that is done we have the option of removing the old syntax or leaving it in as a known oddity. I'd favor removing it, but people who maintain exarboralities for both 2.4 and 2.6 would not thank me. I don't think it's good policy to have the $ and non-$ cases behaving differently if we can avoid it. A good reason to excise the $ case from the tree at first opportunity. Sure, it would cause complaints from people getting too many .rejs from personal trees. But dang it, it's just one line of sed. (Or 'ed' / 'perl -wpi' for in situ editing, depending on whether or not you're Al Viro.) I'm more concerned about subtle dependencies on execution order resulting from misuse of conditionals. Yeah, that's the real reason 'n'!='' is Considered Harmful (and warned about in the docs even now). 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
[kbuild-devel] Re: [patch] config language dep_* enhancements
[Greg Banks] define_bool CONFIG_QUUX y bool 'Set this symbol to ON' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool 'Here QUUX is a query symbol' CONFIG_QUUX fi It's (somewhat) well-known that things tend to fly apart when you try to redefine a symbol. I don't see it documented, but I suppose it should be. In any case, you're supposed to use else - see the example in config-language.txt under === define_hex. 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
[Greg Banks] [I wrote] (BTW, the format is great - I can use 'M-x compile' and 'M-x next-error' and Emacs pulls up files and lines for me.) This is not a coincidence. Indeed not - if you hadn't already used that format I would have munged it. Grew up on gcc, so this is my favorite error message format. Yours too, I guess. (: CONFIG_SCSI should be defined earlier, like in the Block Devices menu. Then again, 'sg' is not a block device so this isn't strictly correct. Perhaps a kernel subsystems submenu under general setup, or even as a toplevel menu. Sounds like a good idea. You could put CONFIG_SERIAL and CONFIG_PCMCIA in there too. CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, though. Minimum necessary change and all that. It's easy enough to add later, if desired. Here's a start. It looks a little hacky but it does fix real issues. I decided to combine general setup, module config and major subsystems - the latter needs to come after modules but really belongs with general setup. Eh? I think the first patch belongs on trivial@rustcorp - what's the protocol there, just an email cc? Attach or inline? etc. Peter diff -urNXxpk 2.5.31/arch/alpha/config.in 2.5.31-1/arch/alpha/config.in --- 2.5.31/arch/alpha/config.in 2002-08-11 15:08:07.0 -0500 +++ 2.5.31-1/arch/alpha/config.in 2002-08-13 20:49:18.0 -0500 -340,6 +340,10 fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in #source drivers/misc/Config.in -375,7 +379,6 endmenu source drivers/usb/Config.in -source drivers/input/Config.in source net/bluetooth/Config.in diff -urNXxpk 2.5.31/arch/mips/config.in 2.5.31-1/arch/mips/config.in --- 2.5.31/arch/mips/config.in 2002-08-11 15:08:07.0 -0500 +++ 2.5.31-1/arch/mips/config.in2002-08-13 20:48:35.0 -0500 -400,6 +400,10 fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in source drivers/media/Config.in -485,7 +489,6 fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -urNXxpk 2.5.31/arch/mips64/config.in 2.5.31-1/arch/mips64/config.in --- 2.5.31/arch/mips64/config.in2002-08-11 15:08:07.0 -0500 +++ 2.5.31-1/arch/mips64/config.in 2002-08-13 20:49:00.0 -0500 -191,6 +191,10 fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in #source drivers/misc/Config.in -232,7 +236,6 fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -urNXxpk 2.5.31-1/arch/alpha/config.in 2.5.31-2/arch/alpha/config.in --- 2.5.31-1/arch/alpha/config.in 2002-08-13 20:49:18.0 -0500 +++ 2.5.31-2/arch/alpha/config.in 2002-08-13 22:07:23.0 -0500 -299,15 +299,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI support' - -tristate 'SCSI support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI support' source drivers/scsi/Config.in + endmenu fi -endmenu if [ $CONFIG_PCI = y ]; then source drivers/message/fusion/Config.in diff -urNXxpk 2.5.31-1/arch/arm/config.in 2.5.31-2/arch/arm/config.in --- 2.5.31-1/arch/arm/config.in 2002-08-11 15:08:07.0 -0500 +++ 2.5.31-2/arch/arm/config.in 2002-08-13 22:07:42.0 -0500 -559,15 +559,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI support' - -tristate 'SCSI support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI support' source drivers/scsi/Config.in + endmenu fi -endmenu if [ $CONFIG_ARCH_CLPS711X = y ]; then source drivers/ssi/Config.in diff -urNXxpk 2.5.31-1/arch/cris/config.in 2.5.31-2/arch/cris/config.in --- 2.5.31-1/arch/cris/config.in2002-07-27 04:14:32.0 -0500 +++ 2.5.31-2/arch/cris/config.in2002-08-13 22:08:01.0 -0500 -153,15 +153,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI support' - -tristate 'SCSI support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI support' source drivers/scsi/Config.in + endmenu fi -endmenu source drivers/ieee1394/Config.in diff -urNXxpk 2.5.31-1/arch/i386/config.in 2.5.31-2/arch/i386/config.in --- 2.5.31-1/arch/i386/config.in2002-08-11 15:08:07.0 -0500 +++ 2.5.31-2/arch/i386/config.in2002-08-13 22:05:49.0 -0500 -311,15 +311,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI device support' - -tristate 'SCSI device support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI device support' source
[kbuild-devel] Re: [patch] config language dep_* enhancements
Kai Germaschewski wrote: On Wed, 14 Aug 2002, Greg Banks wrote: Peter Samuelson wrote: [Greg Banks] Does complete mean all the ports have also made the change and been merged back? [...] Actually I suspect it would be more like the C99 thing: after the new syntax is added, we start doing [TRIVIAL] patches to clean out the old, and eventually once that is done we have the option of removing the old syntax or leaving it in as a known oddity. [...] Well, I think when the switch does not change any behavior, it's actually okay to get it over with in one large but trivial patch. The other approach would be to give the new syntax the new behavior, and do the actual switch piecemeal, checking and fixing dep_* statements as they get converted. I tend to favour the piecemeal approach but I'm not particularly fussed as long as it actually gets done. It'd be nice to introduce a warning for statements where the old syntax is used, but that seems not possible at least in Configure, since I think statements like dep_tristate '...' CONFIG_FOO m should remain valid. In general it seems to me that adding useful warnings to shell-based parsers is difficult. define_bool CONFIG_QUUX y bool 'Set this symbol to ON' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool 'Here QUUX is a query symbol' CONFIG_QUUX fi Well, it's a bug. Agreed, and there several of them in the CML1 corpus, some rather obscure (e.g. the define and the query happen in different Config.in files and only for some architectures). Setting CONFIG_QUUX to y when CONFIG_FOO is n can be done in an else clause to the if statement. If you want to set a default, that's what defconfig is for. Yes. What's nice is that you identified so many problematic cases already, so fixing shouldn't be hard. Like I said, I have a full catalogue of dust puppies ;-) It may still make sense to add code to Configure which recognizes a redefinition and complains or even aborts. This would be a brutally effective way of forcing the problems to be fixed. 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
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
[kbuild-devel] Re: [patch] config language dep_* enhancements
[Greg Banks]
I like the basic idea here, and I'm pleased that someone has the
courage to tackle some of the brokenness of the kconfig language (if
only because it will provide me with a precedent when I try to
submit some of my patches ;-).
Thanks for the feedback. (:
This applies to 2.4.20pre and (except changelog bits) to 2.5.30 with
offsets.
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. Obviously xconfig would need to be dealt with
in sync with the others, which I'm not doing during the prototyping /
idea-mongering stage.
The last statement is inconsistent with the shell code and the
explanations of the dep_* statements, which sensibly preserve the
current semantics where an undefined symbol has a distinct fourth
value which is not y, m or n.
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.
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. Can you provide a rationale for why the current
behavior is desirable? It seems to me that it only encourages buggy
Config.in code (since == n in other contexts like the #defines),
and I don't see any benefits other than that it's the status quo.
[Not to demean the status quo - in 2.4 it is probably appropriate.]
+In addition, the /dep/ may have a prefix !, which negates the
+sense of the /tristate/: !y and !m reduce to n, and !n
+reduces to y.
Perhaps negates isn't quite the right word in four-state logic.
I wasn't sure what else to call it. Besides, as explained above, it's
intended (rightly or wrongly) to be 3-state logic, where two states
represent a form of true. (:
Perhaps the /dep/ may have a prefix !, which transforms the
/tristate/ as follows: ... This is particularly appropriate in light
of Roman's argument (which I buy) in favor of !m == m.
+function dep_calc () {
+ local neg arg
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case $arg in
+ !*) neg=N; arg=${arg#?} ;;
+ esac
+ 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. I'm not really trying
to produce a config.in 'lint' - leave that to the static parsers like
gcml2, xconfig and mconfig.
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
