[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] [patch] kernel config 3/N - move sound into drivers/media
Here's another one - this should fix the forward dependency between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config into the Multimedia menu - where I think it belongs anyway. The big loser here is ARM - it no longer suppresses the sound card question for the appropriate boards. But it's just one question, so I didn't sweat it too much. diff -urNXxpk 2.5.31-2/arch/alpha/config.in 2.5.31w/arch/alpha/config.in --- 2.5.31-2/arch/alpha/config.in 2002-08-13 22:07:23.0 -0500 +++ 2.5.31w/arch/alpha/config.in2002-08-13 22:38:58.0 -0500 -366,15 +366,6 endmenu fi -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in source net/bluetooth/Config.in diff -urNXxpk 2.5.31-2/arch/arm/config.in 2.5.31w/arch/arm/config.in --- 2.5.31-2/arch/arm/config.in 2002-08-13 22:07:42.0 -0500 +++ 2.5.31w/arch/arm/config.in 2002-08-13 22:43:26.0 -0500 -630,22 +630,6 endmenu fi -if [ $CONFIG_ARCH_ACORN = y -o \ - $CONFIG_ARCH_CLPS7500 = y -o \ - $CONFIG_ARCH_TBOX = y -o \ - $CONFIG_ARCH_SHARK = y -o \ - $CONFIG_ARCH_SA1100 = y -o \ - $CONFIG_PCI = y ]; then - mainmenu_option next_comment - comment 'Sound' - - tristate 'Sound card support' CONFIG_SOUND - if [ $CONFIG_SOUND != n ]; then - source sound/Config.in - fi - endmenu -fi - source drivers/misc/Config.in source drivers/usb/Config.in diff -urNXxpk 2.5.31-2/arch/cris/config.in 2.5.31w/arch/cris/config.in --- 2.5.31-2/arch/cris/config.in2002-08-13 22:08:01.0 -0500 +++ 2.5.31w/arch/cris/config.in 2002-08-13 22:43:45.0 -0500 -205,15 +205,6 source fs/Config.in -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in mainmenu_option next_comment diff -urNXxpk 2.5.31-2/arch/i386/config.in 2.5.31w/arch/i386/config.in --- 2.5.31-2/arch/i386/config.in2002-08-13 22:05:49.0 -0500 +++ 2.5.31w/arch/i386/config.in 2002-08-13 23:06:04.0 -0500 -385,15 +385,6 endmenu fi -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in source net/bluetooth/Config.in diff -urNXxpk 2.5.31-2/arch/ia64/config.in 2.5.31w/arch/ia64/config.in --- 2.5.31-2/arch/ia64/config.in2002-08-13 22:08:38.0 -0500 +++ 2.5.31w/arch/ia64/config.in 2002-08-13 22:44:28.0 -0500 -217,15 +217,6 if [ $CONFIG_IA64_HP_SIM = n ]; then -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in source lib/Config.in diff -urNXxpk 2.5.31-2/arch/mips/config.in 2.5.31w/arch/mips/config.in --- 2.5.31-2/arch/mips/config.in2002-08-13 22:09:54.0 -0500 +++ 2.5.31w/arch/mips/config.in 2002-08-13 22:47:58.0 -0500 -471,17 +471,6 endmenu fi -if [ $CONFIG_DECSTATION != y ]; then - mainmenu_option next_comment - comment 'Sound' - - tristate 'Sound card support' CONFIG_SOUND - if [ $CONFIG_SOUND != n ]; then - source sound/Config.in - fi - endmenu -fi - if [ $CONFIG_SGI_IP22 = y ]; then source drivers/sgi/Config.in fi diff -urNXxpk 2.5.31-2/arch/mips64/config.in 2.5.31w/arch/mips64/config.in --- 2.5.31-2/arch/mips64/config.in 2002-08-13 22:10:16.0 -0500 +++ 2.5.31w/arch/mips64/config.in 2002-08-13 22:48:17.0 -0500 -219,15 +219,6 define_bool CONFIG_KCORE_ELF y fi -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - if [ $CONFIG_SGI_IP22 = y ]; then source drivers/sgi/Config.in fi diff -urNXxpk 2.5.31-2/arch/ppc/config.in 2.5.31w/arch/ppc/config.in --- 2.5.31-2/arch/ppc/config.in 2002-08-13 22:14:09.0 -0500 +++ 2.5.31w/arch/ppc/config.in 2002-08-13 22:54:57.0 -0500 -558,15 +558,6 source fs/Config.in -mainmenu_option next_comment -comment 'Sound' -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/oss/dmasound/Config.in - source sound/Config.in -fi -endmenu - if [ $CONFIG_8xx = y ]; then source arch/ppc/8xx_io/Config.in fi diff -urNXxpk 2.5.31-2/arch/ppc64/config.in 2.5.31w/arch/ppc64/config.in --- 2.5.31-2/arch/ppc64/config.in 2002-08-13 22:14:24.0 -0500 +++ 2.5.31w/arch/ppc64/config.in2002-08-13 22:56:14.0 -0500 -197,15 +197,6 source fs/Config.in -mainmenu_option next_comment -comment 'Sound' -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Tue, 13 Aug 2002, Peter Samuelson wrote: Here's another one - this should fix the forward dependency between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config into the Multimedia menu - where I think it belongs anyway. Hmmh, makes sense to me, but there will probably be people complaining sound config has disappeared for me ;) The big loser here is ARM - it no longer suppresses the sound card question for the appropriate boards. But it's just one question, so I didn't sweat it too much. Well, I think that's okay, but you should check back with _rmk_. What I like about that patch is that it actually removes duplicated code. I think that's exactly where this effort should start. For example, the SCSI patch didn't do this, though AFAICS it would be nicely possible to unconditionally source drivers/scsi/Config.in and then have the if in there. These are trivial changes, and they make it easier to see what's happening in the patches which actually change behavior. Taking that a step further, this should also be a nice opportunity to introduce drivers/Config.in and remove even more duplication from arch/$ARCH/config.in. It comes of the cost of testing for the architecture, since e.g. s390 does not want to include most of drivers/*, but that means we'd actually collect this knowledge at a centralized place. Introducing drivers/Config.in could be done nicely piecemeal as well, without any change in behavior which is always good. It would also provide a possibility to not lose the ARM knowledge. I think it's basically just a question of taste if you prefer to initial global subsystem question in drivers/Config.in or drivers/subsys/Config.in. drivers/isdn/Config.in starts with mainmenu_option next_comment comment 'ISDN subsystem' if [ $CONFIG_NET != n ]; then bool 'ISDN support' CONFIG_ISDN_BOOL if [ $CONFIG_ISDN_BOOL = y ]; then mainmenu_option next_comment since I did not like having that duplicated in each arch/*/config.in. It also makes sense in the have as much information as possible about a subsystem located in one place (drivers/subsys). By the way, if you do these kind of changes, also check Config.help, you may be able to remove duplicated entries there as well ;) The drawbacks of that solution as opposed to having the above in drivers/Config.in and ending with source drivers/isdn/Config.in are: o We need to source all the Config.in files even when the subsys gets disabled, since we cannot know that beforehand o The trivial patches moving statements like the above into the subsys/Config.in means that all of that file should be indented, which makes the patches look really large, even though they change very little. I have no strong opinion either way, but I'd certainly like a drivers/Config.in. Oh, what I don't like about your patches: You don't include them inline, so I cannot easily (R)eply to them and have them quoted ;) --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 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] kernel config 3/N - move sound into drivers/media
[I wrote] Here's another one - this should fix the forward dependency between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config into the Multimedia menu - where I think it belongs anyway. [Kai Germaschewski] Hmmh, makes sense to me, but there will probably be people complaining sound config has disappeared for me ;) You are probably right. I still think it's the right thing to do. (: I do *not* like the recent proliferation of toplevel menu entries. Well, I think that's okay, but you should check back with _rmk_. True. The trouble with this sort of work is that you *have* to touch all the architectures, and sometimes change the behavior somewhat. That can mean stepping on toes now and then. What I like about that patch is that it actually removes duplicated code. I think that's exactly where this effort should start. For example, the SCSI patch didn't do this, though AFAICS it would be nicely possible to unconditionally source drivers/scsi/Config.in and then have the if in there. I thought about that - but didn't want to re-indent the whole file. I hate doing that. (: Also, there's a *reason* every arch has a separate config.in file - for maximum flexibility without putting lots of ifdefs in common code. To a certain extent I agree with you and I wish it were possible to eliminate the arch/*/config.in entirely, but it's not. ESR tried it with CML2 and was slapped down by Linus himself, as I recall. I don't want my humble efforts to end up the same way CML2 did. For that reason I'm trying very hard to make only small, incremental, obvious changes. Perhaps I'm a bit *too* timid. It comes of the cost of testing for the architecture, since e.g. s390 does not want to include most of drivers/*, but that means we'd actually collect this knowledge at a centralized place. What we need is an easy way to check for any arch. CONFIG_ARCH_S390 is the right idea (though s390x sets it as well, not sure if that's good or bad). Then again, such checks polluting the common code is exactly what the current system (with all its cut/paste code in arch/*/config.in) is supposed to prevent. Perhaps The Powers That Be like the status quo. Introducing drivers/Config.in could be done nicely piecemeal as well, without any change in behavior which is always good. It would also provide a possibility to not lose the ARM knowledge. H ... I didn't see any clean way to keep the arm test. Thinking about it some more, I suppose one could do if [ $CONFIG_ARM = y ]; then if [ ... ]; then tristate CONFIG_SOUND fi else tristate CONFIG_SOUND fi It's still not pretty, but should work. I think I'll put that in drivers/media/Config.in. By the way, if you do these kind of changes, also check Config.help, you may be able to remove duplicated entries there as well ;) I'd been avoiding Config.help - I was afraid if I looked in it I would find entries I would have to move from one dir to another. (: I have no strong opinion either way, but I'd certainly like a drivers/Config.in. Agreed. Oh, what I don't like about your patches: You don't include them inline, so I cannot easily (R)eply to them and have them quoted ;) Sorry about that - I agree. I only attached patches when I had more than one for a single mail, and then I forgot to switch back. Must recompile self with -finline-patches 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
