linux-kernel - Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0706221400o613fe6a6ib1cdb066057f31a6@mail.gmail.com>
Date:	Sat, 23 Jun 2007 02:30:31 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Jan Engelhardt" <jengelh@...putergmbh.de>
Cc:	"Roman Zippel" <zippel@...ux-m68k.org>,
	"Mauro Carvalho Chehab" <mchehab@...radead.org>,
	"Oliver Neukum" <oneukum@...e.de>,
	linux-usb-devel@...ts.sourceforge.net, video4linux-list@...hat.com,
	"Toralf F�rster" <toralf.foerster@....de>,
	luca.risolia@...dio.unibo.it, LKML <linux-kernel@...r.kernel.org>
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@...il.com> wrote:
> Hi Jan,
>
> On 6/22/07, Jan Engelhardt <jengelh@...putergmbh.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/