Messages in this thread | | | Date | Sat, 23 Jun 2007 02:30:31 +0530 | From | "Satyam Sharma" <> | Subject | Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c |
| |
On 6/23/07, Satyam Sharma <satyam.sharma@gmail.com> wrote: > Hi Jan, > > On 6/22/07, Jan Engelhardt <jengelh@computergmbh.de> wrote: > > > > On Jun 22 2007 18:24, Roman Zippel wrote: > > > > > >> There have been discussions to remove the default-ys again, I've sent a patch > > >> [http://lkml.org/lkml/2007/5/12/216], but nothing happened. > > >> > > >> So, should all affected menuconfigs be transformed into tristates, what > > >> do you think, Roman? Let me know so I can cook up a patch (hopefully > > >> before 2.6.22) should they become tristate. > > > > > >Using bool is clearly a bug and I'd prefer if it removed the defaults as > > >well. > > > > What I don't quite understand is, that CONFIG_CRYPTO is also a bool, > > its subparts are tristates however, and there is no problem involved > > with these. > > That's because neither CONFIG_CRYPTO nor any of the crypto modules > depend on another symbol that is itself tristate (and hence can be modular), > which is the case with all the problematic cases that have been posted to > lkml lately.
To elaborate, the problem is:
menuconfig FOO bool "FOO support drivers" depends on BAR
if FOO
config BAZ tristate "BAZ driver"
endif # FOO
Where:
config BAR tristate "BAR subsystem"
The problem occurs when: BAR=m FOO=y (user selects FOO to show menu to be able to then select BAZ) BAZ=y
BAZ would be built-in, BAR modular => build breakage. Note that it is *BAZ* that depends on BAR. BAZ is *code* in the kernel sources, and depends on BAR because it calls *code* exported by BAR (obviously).
[ We've marked _FOO_ as "depends on BAR" too, however, but that is only because all the related drivers that this menu shows / hides have the common property that they depend on BAR and hence there's no point in showing this menu option to the user unless he has picked BAR already.]
The root cause of the problem, as Randy Dunlap pointed out yesterday, is a boolean coming in between the dependency chain of 2 tristates: BAZ (tristate) depends on FOO (bool) depends on BAR (tristate).
BAR=m _does_ allow its dependency FOO to be "y", which then allows BAZ (marked as dependency of only FOO but not BAR too, sadly) to be "y".
Solution 1:
Make all FOO-like configmenu's trisate. => if BAR=m => FOO can only be m too => BAZ can only be m too.
But making a menuconfig symbol tristate is ugly, IMHO. These new primitives are just on/off switches to show / hide a further menu that contains related drivers / options, after all. They are bool's by meaning, and need to defined / used as such too. [my opinion, fwiw]
Solution 2:
Explicitly honour the dependency of BAZ on BAR.
2.(a) do this either explicitly by adding "depends on" in kconfig itself:
config BAZ tristate "BAZ driver" depends on BAR
=> do this for all the config symbols inside any if FOO / endif block where FOO depends on some other tristate symbol itself. But this sounds (and feels like being) redundant.
2.(b) or else, make the config scripts "intelligent" so that if:
"menuconfig FOO depends on BAR", then:
All the "config BAZ"s inside this menuconfig (inside the if FOO / endif block) also automatically "depend on" BAR too.
I would vote for solution 2.(b), personally, but solution 1 is easiest.
Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |