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

[Satyam Sharma]

On 6/23/07, Satyam Sharma <satyam.sharma@xxxxxxxxx> wrote:
> Hi Jan,
>
> On 6/22/07, Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/