From: "Satyam Sharma" <satyam.sharma@gmail.com>
To: "Jan Engelhardt" <jengelh@computergmbh.de>
Cc: "Roman Zippel" <zippel@linux-m68k.org>,
"Mauro Carvalho Chehab" <mchehab@infradead.org>,
"Oliver Neukum" <oneukum@suse.de>,
linux-usb-devel@lists.sourceforge.net,
video4linux-list@redhat.com,
"Toralf F�rster" <toralf.foerster@gmx.de>,
luca.risolia@studio.unibo.it, LKML <linux-kernel@vger.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
Date: Sat, 23 Jun 2007 02:30:31 +0530 [thread overview]
Message-ID: <a781481a0706221400o613fe6a6ib1cdb066057f31a6@mail.gmail.com> (raw)
In-Reply-To: <a781481a0706221317q3dd49905j8773b2f8a96ad63b@mail.gmail.com>
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
next prev parent reply other threads:[~2007-06-22 21:00 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200706211117.55908.toralf.foerster@gmx.de>
[not found] ` <200706211231.53898.luca.risolia@studio.unibo.it>
[not found] ` <200706211326.45031.toralf.foerster@gmx.de>
[not found] ` <200706211350.14526.oneukum@suse.de>
2007-06-22 13:22 ` Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c Mauro Carvalho Chehab
2007-06-22 13:46 ` Andreas Herrmann
2007-06-22 13:51 ` Jan Engelhardt
2007-06-22 14:23 ` Andreas Herrmann
2007-06-22 15:03 ` Mauro Carvalho Chehab
2007-06-22 15:32 ` Andreas Herrmann
2007-06-22 15:45 ` Oliver Neukum
2007-06-22 14:27 ` Roman Zippel
2007-06-22 15:18 ` Jan Engelhardt
2007-06-22 16:24 ` Roman Zippel
2007-06-22 16:42 ` Jan Engelhardt
2007-06-22 20:17 ` Satyam Sharma
2007-06-22 21:00 ` Satyam Sharma [this message]
2007-06-22 15:21 ` Mauro Carvalho Chehab
2007-06-22 16:31 ` Roman Zippel
2007-06-22 20:20 ` Trent Piepho
2007-06-22 21:20 ` Satyam Sharma
2007-06-22 21:45 ` Roman Zippel
2007-06-22 22:01 ` Satyam Sharma
2007-06-22 22:21 ` Roman Zippel
2007-06-22 22:33 ` Satyam Sharma
2007-06-22 23:12 ` Roman Zippel
2007-06-22 23:26 ` Satyam Sharma
2007-06-22 23:39 ` Roman Zippel
2007-06-22 23:49 ` Satyam Sharma
2007-06-23 0:26 ` Roman Zippel
2007-06-23 6:57 ` Jan Engelhardt
2007-06-25 0:11 ` Roman Zippel
2007-06-22 22:11 ` Jan Engelhardt
2007-06-23 12:28 ` Kconfig troubles when using menuconfig - Was: [patch]Re: " Oleg Verych
2007-06-23 22:33 ` Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] " Trent Piepho
2007-06-24 3:28 ` Satyam Sharma
2007-06-23 7:20 ` [patch] 2.6.22-rc Kconfig troubles when using menuconfig Jan Engelhardt
2007-06-23 22:26 ` Mauro Carvalho Chehab
2007-06-24 0:14 ` Trent Piepho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a781481a0706221400o613fe6a6ib1cdb066057f31a6@mail.gmail.com \
--to=satyam.sharma@gmail.com \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=luca.risolia@studio.unibo.it \
--cc=mchehab@infradead.org \
--cc=oneukum@suse.de \
--cc=toralf.foerster@gmx.de \
--cc=video4linux-list@redhat.com \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).