[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Tue, Aug 13, 2002 at 11:35:58PM -0500, Peter Samuelson wrote: 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. I'd be tempted to drop that set of tests, and just rely on the per-driver stuff, where its sane to do so. There's no way we can special case all the drivers out there for each machine type in the generic config files. That is the route to madness. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html --- 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] kernel config 3/N - move sound into drivers/media
On Wednesday 14 August 2002 07:49, Peter Samuelson wrote: [Kai Germaschewski] 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). It's not logical, but it tends to help because it's what's meant most of the time. I don't know a single place in the kernel where you want to test for (CONFIG_ARCH_S390 !CONFIG_ARCH_S390X). Rather than making everything depend on CONFIG_ARCH_THIS CONFIG_ARCH_THAT, I'd prefer if every driver depended on its bus type. With the new driver model, every driver has a clearly defined bus type and driver class, so it would be logical to have that driver option exactly when these two are enabled. Of course, that probably means a huge amount of work but it helps avoid problems when a new architecture is added or an existing one gets a new bus. E.g., s390 used to have no support for SCSI, but with the zfcp driver we enable drivers/scsi/Config.in, so now we get a lot of questions about drivers that won't work. Enclosing the drivers in CONFIG_ARCH_s390 != y does help us, but it would still be wrong to do that for a Sparc kernel that supports some of the PCI cards but not the ISA ones. Arnd --- 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, 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
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Wed, 14 Aug 2002, Greg Banks wrote: @@ -330,6 +329,5 @@ 1 CONFIG_ZORRO -34 forward-dependancy +23 forward-dependancy 11 CONFIG_ISDN_CAPI 11 CONFIG_PROC_FS -11 CONFIG_SOUND_ACI_MIXER 1 CONFIG_BLK_DEV_SD Could you check that the appended patch solves the CONFIG_ISDN_CAPI problem (and doesn't introduce new ones)? --Kai = drivers/isdn/Config.in 1.18 vs edited = --- 1.18/drivers/isdn/Config.in Wed Apr 24 09:42:33 2002 +++ edited/drivers/isdn/Config.in Wed Aug 14 10:49:07 2002 @@ -22,8 +22,9 @@ tristate 'CAPI2.0 support' CONFIG_ISDN_CAPI if [ $CONFIG_ISDN_CAPI != n ]; then source drivers/isdn/capi/Config.in - source drivers/isdn/hardware/Config.in fi + + source drivers/isdn/hardware/Config.in fi fi endmenu = drivers/isdn/hardware/Config.in 1.1 vs edited = --- 1.1/drivers/isdn/hardware/Config.in Sun Apr 21 23:07:44 2002 +++ edited/drivers/isdn/hardware/Config.in Wed Aug 14 11:01:04 2002 @@ -2,4 +2,26 @@ # ISDN hardware drivers # -source drivers/isdn/hardware/avm/Config.in +if [ $CONFIG_ISDN_CAPI != n ]; then + comment 'CAPI hardware drivers' + source drivers/isdn/hardware/avm/Config.in +fi + +if [ $CONFIG_ISDN != n ]; then + comment 'ISDN4Linux hardware drivers' + + source drivers/isdn/hisax/Config.in + + mainmenu_option next_comment + comment 'Active cards' + + source drivers/isdn/icn/Config.in + source drivers/isdn/pcbit/Config.in + source drivers/isdn/sc/Config.in + source drivers/isdn/act2000/Config.in + source drivers/isdn/eicon/Config.in + source drivers/isdn/tpam/Config.in + source drivers/isdn/hysdn/Config.in + endmenu +fi + = drivers/isdn/hardware/avm/Config.in 1.3 vs edited = --- 1.3/drivers/isdn/hardware/avm/Config.in Tue Jun 18 14:00:47 2002 +++ edited/drivers/isdn/hardware/avm/Config.in Wed Aug 14 10:53:57 2002 @@ -3,7 +3,7 @@ # mainmenu_option next_comment -comment 'Drivers for active AVM cards' +comment 'Active AVM cards' bool 'Support AVM cards' CONFIG_CAPI_AVM = drivers/isdn/hisax/Config.in 1.9 vs edited = --- 1.9/drivers/isdn/hisax/Config.inTue Jul 30 07:15:09 2002 +++ edited/drivers/isdn/hisax/Config.in Wed Aug 14 11:01:20 2002 @@ -1,5 +1,5 @@ mainmenu_option next_comment -comment 'Passive ISDN cards' +comment 'Passive cards' dep_tristate 'HiSax SiemensChipSet driver support' CONFIG_ISDN_DRV_HISAX $CONFIG_ISDN if [ $CONFIG_ISDN_DRV_HISAX != n ]; then comment ' D-channel protocol features' = drivers/isdn/i4l/Config.in 1.3 vs edited = --- 1.3/drivers/isdn/i4l/Config.in Sun Apr 21 23:07:44 2002 +++ edited/drivers/isdn/i4l/Config.in Wed Aug 14 10:47:42 2002 @@ -24,22 +24,5 @@ dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN endmenu -comment 'low-level hardware drivers' - -source drivers/isdn/hisax/Config.in - -### Active ISDN cards - -mainmenu_option next_comment -comment 'Active ISDN cards' - -source drivers/isdn/icn/Config.in -source drivers/isdn/pcbit/Config.in -source drivers/isdn/sc/Config.in -source drivers/isdn/act2000/Config.in -source drivers/isdn/eicon/Config.in -source drivers/isdn/tpam/Config.in -source drivers/isdn/hysdn/Config.in - endmenu --- 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] Get rid of shell based Config.in parsers?
On Wed, Aug 14, 2002 at 10:22:55AM +1000, Greg Banks wrote: The trouble is actually achieving that in shell-based parsers where shell code cannot tell whether $CONFIG_EXPERIMENTAL has been used in a condition. Where comes the requirement that we shall keep the existing shell based config parsers? Remembering the CML2 war there were no serious objections about shifting away from shell based parsers (but certainly a lot about the alternative selected). It is possible to replace Configure and menuconfig rather easy and then see if a new xconfig showed up based on the new parsers. This would allow us to do much more advanced semantic checks, and give proper warnings to catch errors early. The first versions should obviously not introduce new syntax, that should evolve over time. I dislike seeing arguments that this is not easy/possible in shell based parsers. If the chosen technology does not fit the problem domain then it's about time to shift technology. 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] Get rid of shell based Config.in parsers?
[Sam Ravnborg] Where comes the requirement that we shall keep the existing shell based config parsers? I don't make that argument - mconfig is the superior solution by far - but it is certainly the path of least resistance. As pertains to CONFIG_EXPERIMENTAL and (EXPERIMENTAL), it *is* possible to add such a feature to the shell-based parsers by changing the syntax slightly - specifically to lose the '$' on dependencies. Changing the syntax *does* have ramifications when it means adapting three separate parsers, but it can be done. Remembering the CML2 war there were no serious objections about shifting away from shell based parsers (but certainly a lot about the alternative selected). It would have been a big change and a big flag day, and among other problems, the rulebase conversion issue was handled wrong. Eric refused to start from a 1-1 equivalent rulebase, preferring to tweak the rulebase as he went along - partly just to fix bugs, partly to show off his new capabilities. Unfortunately, without the apples-to-apples comparison, many people distrusted the new system, superior though it was in many ways. This is the primary lesson to be learned from CML2. Anyone trying to redesign a subsystem such as the kernel config system needs to keep it in mind. (Yes, I know from the rest of your message that you learned it.) 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] [patch] remove duplicated AGP Config.in
drivers/char/Config.in still has a complete copy of agp/Config.in. It's an exact cut-n-paste - the md5sums even match. (: --- 2.5.31/drivers/char/Config.in~ 2002-08-08 22:43:28.0 -0500 +++ 2.5.31/drivers/char/Config.in 2002-08-14 17:25:20.0 -0500 @@ -173,21 +173,7 @@ fi endmenu -dep_tristate '/dev/agpgart (AGP Support)' CONFIG_AGP $CONFIG_DRM_AGP -if [ $CONFIG_AGP != n ]; then - bool ' Intel 440LX/BX/GX and I815/I820/I830M/I830MP/I840/I845/I850/I860 support' CONFIG_AGP_INTEL - bool ' Intel I810/I815/I830M (on-board) support' CONFIG_AGP_I810 - bool ' VIA chipset support' CONFIG_AGP_VIA - bool ' AMD Irongate, 761, and 762 support' CONFIG_AGP_AMD - bool ' Generic SiS support' CONFIG_AGP_SIS - bool ' ALI chipset support' CONFIG_AGP_ALI - bool ' Serverworks LE/HE support' CONFIG_AGP_SWORKS - if [ $CONFIG_IA64 = y ]; then - bool ' Intel 460GX support' CONFIG_AGP_I460 - bool ' HP ZX1 AGP support' CONFIG_AGP_HP_ZX1 - fi -fi - +source drivers/char/agp/Config.in source drivers/char/drm/Config.in if [ $CONFIG_HOTPLUG = y -a $CONFIG_PCMCIA != n ]; then --- 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
[kbuild-devel] RFC: kernel config: new dependency syntax
[I 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.
I've come up with syntax I think I'm happy with. It supports most of
the current [ ] based if statement semantics, can be implemented in
shell, and (most importantly for me) drops those $ signs. This lays
the groundwork for stuff like better error checking and auto
(EXPERIMENTAL) tags.
I made a proof-of-concept patch for Menuconfig. The Configure patch
would be very similar; God only knows what xconfig or mconfig would
require.
I've reused the syntax for a dependency line (the tail end of a
dep_bool / dep_mbool / dep_tristate), like so:
if_dep idependency line/i
...
endif
If the dependency line evaluates to 'm' or 'y', the body is executed.
Now with our current dep_* syntax, this isn't very powerful. I've
made a few extensions which are, I believe, almost enough[*] to
displace the current use of test(1)-based 'if' statements. Some of
this syntax is not really needed for dep_* lines, but I *really* like
having a single backend function for all of dep_bool, dep_tristate and
if_dep.
[*] almost enough because I haven't implemented an 'else'
directive. It would be trivial, but I'm not sure what to call it.
'else' itself is a shell primitive, so the shell-based parsers
(Configure, Menuconfig) wouldn't like it.
* '$CONFIG_FOO' can and should be replaced with 'CONFIG_FOO' without
the $. My current patch accepts both; eventually we might drop
backwards compatibility.
* !CONFIG_FOO negates sense: !y==n, !n==y, !==y, !m==m. The last
!m==m is due to Roman's observation that it is useful to exclude two
things from both being Y while allowing them to both be M.
* 'or' placed between dependencies functions as a logical OR, and
takes very low precedence. This complements the implicit AND
performed between every pair of dependencies.
x or x - x, for any x
n or m == m or n - m
n or y == y or n - y
m or y == y or m - y
* A=B evaluates to either Y or N, depending on whether A is logically
equivalent to B. It has higher precedence than the ! operator.
Thus:
CONFIG_FOO=m evaluates to 'y' if CONFIG_FOO is m, 'n' otherwise
CONFIG_BAR=n evaluates to 'y' if CONFIG_BAR is n or empty, 'n' otherwise
!CONFIG_BAZ=y evaluates to 'n' if CONFIG_BAZ is y, 'y' otherwise
This syntax is fully backward-compatible. Examples of use:
if_dep CONFIG_X86 or CONFIG_X86_64 or CONFIG_IA64
bool 'ACPI support' CONFIG_ACPI
endif
if_dep CONFIG_SOUND !CONFIG_SOUND_ALSA
source sound/oss/Config.in
endif
dep_tristate 'Adaptec (new driver)' CONFIG_AIC7XXX_NEW !CONFIG_AIC7XXX_OLD
dep_tristate 'Adaptec (old driver)' CONFIG_AIC7XXX_OLD !CONFIG_AIC7XXX_NEW
The one thing I wanted to specify but didn't is an 'else' statement.
The problem is that I can't think what to call it - can't use 'else'
because the shell-based parsers (Configure, Menuconfig) will choke on
it. Any ideas?
Any other comments? Am I going in totally the wrong direction?
Peter
--- 2.5.31/scripts/Menuconfig 2002-06-09 00:27:32.0 -0500
+++ 2.5.31w/scripts/Menuconfig 2002-08-14 21:00:27.0 -0500
@@ -73,7 +73,10 @@
# - Support for multiple conditions in dep_tristate().
# - Implemented new functions: define_tristate(), define_int(), define_hex(),
# define_string(), dep_bool().
-#
+#
+# 14 Aug 2002, Peter Samuelson [EMAIL PROTECTED]
+# - add lots of new syntax for dependencies in 'dep_*' functions
+# - also use this syntax for a new 'if_dep' / 'endif' primitive
#
@@ -112,6 +115,67 @@
eval info=\$INFO_$1
}
+
+# Reduce a dependency line down to a single char [ymn].
+# Terms are implicitly ANDed together: 'y m' = 'm y' = m, '... n' = 'n ...' = n
+# Each term can be:
+# 'y', 'm', 'n' interpreted as-is
+# 'CONFIG_FOO' reduces to value of CONFIG_FOO, or 'n' if unset
+# 'or' OR operator, lower precedence than the implicit AND
+# specifics: 'y or ...' = '... or y' = y
+# if no 'y': 'm or ...' = '... or m' = m
+# term=value tested for equality, replaced with 'y' or 'n'
+# !term negate value of term: y-n, n-y, m-m, ''-y
+# Note that there is no grouping construct.
+# Use boolean transforms, or nest conditionals.
+function dep_calc () {
+ local neg arg ordep
+ if [ $nest_ifdep = n ]; then
+ cur_dep=n;
+ return 1;
+ fi
+ ordep=n
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case $arg in
+ or)
+ case $ordep in
+ n) ordep=$cur_dep ;;
+ m) [ $cur_dep = y ] ordep=y ;;
+ esac
+ cur_dep=y; continue ;;
+
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
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
Peter Samuelson wrote: I've come up with syntax I think I'm happy with. It supports most of the current [ ] based if statement semantics, can be implemented in shell, and (most importantly for me) drops those $ signs. This lays the groundwork for stuff like better error checking and auto (EXPERIMENTAL) tags. I've reused the syntax for a dependency line (the tail end of a dep_bool / dep_mbool / dep_tristate), like so: if_dep idependency line/i ... endif If the dependency line evaluates to 'm' or 'y', the body is executed. Hmm. Perhaps (I haven't completely thought this through) by analogy with dep_bool/dep_mbool, you would want two new if statements which differ in the way they treat 'm'? If the conditional syntax is the same people may expect that. Also you will want to define the behaviour when the line evaluates to 0. ./arch/sparc64/config.in:180:if [ $CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS = 0 ]; then ./drivers/scsi/Config.in:166: if [ $CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS = 0 ]; then [*] almost enough because I haven't implemented an 'else' directive. It would be trivial, but I'm not sure what to call it. 'else' itself is a shell primitive, so the shell-based parsers (Configure, Menuconfig) wouldn't like it. You will need to implement it. You could call it elsedep. * 'or' placed between dependencies functions as a logical OR, and takes very low precedence. This complements the implicit AND performed between every pair of dependencies. x or x - x, for any x n or m == m or n - m n or y == y or n - y m or y == y or m - y How about an 'and' operator too, which is redundant but more readable. --- 2.5.31/scripts/Menuconfig 2002-06-09 00:27:32.0 -0500 +++ 2.5.31w/scripts/Menuconfig 2002-08-14 21:00:27.0 -0500 @@ -112,6 +115,67 @@ eval info=\$INFO_$1 } + +# Reduce a dependency line down to a single char [ymn]. +# Terms are implicitly ANDed together: 'y m' = 'm y' = m, '... n' = 'n ...' = n Also 'y y' = y I'll look at the rest when there's an else. 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
