Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
> Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster:
> > Right, but IMHO this issue is typical for a problem with the Kconfig definitions of this module.
> >
> > I'll set USB devs as Cc: therefore.
>
> The Kconfig there is incomplete.
> Mauro, please apply.
>
> Regards
> Oliver
> Signed-off-by: Oliver Neukum <[email protected]>
>
> --- a/drivers/media/video/zc0301/Kconfig 2007-06-21 13:44:14.000000000 +0200
> +++ b/drivers/media/video/zc0301/Kconfig 2007-06-21 13:44:33.000000000 +0200
> @@ -1,6 +1,6 @@
> config USB_ZC0301
> tristate "USB ZC0301[P] Image Processor and Control Chip support"
> - depends on VIDEO_V4L1
> + depends on VIDEO_V4L1 && USB
> ---help---
> Say Y here if you want support for cameras based on the ZC0301 or
> ZC0301P Image Processors and Control Chips.
>
In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS,
that depends, in turn, on USB. So, if USB is not selected,
V4L_USB_DRIVERS should be unselected, unselecting zc0301.
Unfortunately, the Kernel building system is not properly handling it.
This is the (snipped) media/video/Kconfig:
menuconfig V4L_USB_DRIVERS
bool "V4L USB devices"
depends on USB
default y
if V4L_USB_DRIVERS
source "drivers/media/video/pvrusb2/Kconfig"
<snip/>
source "drivers/media/video/zc0301/Kconfig"
<snip/>
endif # V4L_USB_DRIVERS
--
Cheers,
Mauro
On Fri, Jun 22, 2007 at 10:22:46AM -0300, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
>
> Em Qui, 2007-06-21 ?s 13:50 +0200, Oliver Neukum escreveu:
> > Am Donnerstag, 21. Juni 2007 schrieb Toralf F?rster:
> > > Right, but IMHO this issue is typical for a problem with the Kconfig definitions of this module.
> > >
> > > I'll set USB devs as Cc: therefore.
> >
> > The Kconfig there is incomplete.
> > Mauro, please apply.
> >
> > Regards
> > Oliver
> > Signed-off-by: Oliver Neukum <[email protected]>
> >
> > --- a/drivers/media/video/zc0301/Kconfig 2007-06-21 13:44:14.000000000 +0200
> > +++ b/drivers/media/video/zc0301/Kconfig 2007-06-21 13:44:33.000000000 +0200
> > @@ -1,6 +1,6 @@
> > config USB_ZC0301
> > tristate "USB ZC0301[P] Image Processor and Control Chip support"
> > - depends on VIDEO_V4L1
> > + depends on VIDEO_V4L1 && USB
> > ---help---
> > Say Y here if you want support for cameras based on the ZC0301 or
> > ZC0301P Image Processors and Control Chips.
> >
>
> In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS,
> that depends, in turn, on USB. So, if USB is not selected,
> V4L_USB_DRIVERS should be unselected, unselecting zc0301.
>
> Unfortunately, the Kernel building system is not properly handling it.
>
> This is the (snipped) media/video/Kconfig:
>
> menuconfig V4L_USB_DRIVERS
> bool "V4L USB devices"
> depends on USB
> default y
>
> if V4L_USB_DRIVERS
>
> source "drivers/media/video/pvrusb2/Kconfig"
>
> <snip/>
>
> source "drivers/media/video/zc0301/Kconfig"
>
> <snip/>
>
> endif # V4L_USB_DRIVERS
>
> --
> Cheers,
> Mauro
>
Hi,
I am not sure whether it is related or not
But if you select USB as module but build your v4l_usb driver
into the kernel you also get compile errors.
Attached is a patch which will prevent this by changing the menuconfig
from bool to tristate.
Regards,
Andreas
--
Correct Kconfig to avoid compile errors like
drivers/built-in.o: In function `sn9c102_usb_disconnect':
sn9c102_core.c:(.text+0x8d840): undefined reference to `usb_get_dev'
Signed-off-by: Andreas Herrmann <[email protected]>
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4cca551..4754d98 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -687,7 +687,7 @@ config VIDEO_CAFE_CCIC
#
menuconfig V4L_USB_DRIVERS
- bool "V4L USB devices"
+ tristate "V4L USB devices"
depends on USB
default y
On Jun 22 2007 15:46, Andreas Herrmann wrote:
>Hi,
>
>I am not sure whether it is related or not
>But if you select USB as module but build your v4l_usb driver
>into the kernel you also get compile errors.
>Attached is a patch which will prevent this by changing the menuconfig
>from bool to tristate.
A config option that is not referenced in the Makefile...
should it really be a tristate? In my opinion, changing it
to tristate is just a workaround, but I don't know kconfig
well enough to make bool Do The Right Thing in these situations myself :(
Jan
--
On Fri, Jun 22, 2007 at 03:51:34PM +0200, Jan Engelhardt wrote:
>
> On Jun 22 2007 15:46, Andreas Herrmann wrote:
> >Hi,
> >
> >I am not sure whether it is related or not
> >But if you select USB as module but build your v4l_usb driver
> >into the kernel you also get compile errors.
> >Attached is a patch which will prevent this by changing the menuconfig
> >from bool to tristate.
>
> A config option that is not referenced in the Makefile...
> should it really be a tristate? In my opinion, changing it
> to tristate is just a workaround, but I don't know kconfig
> well enough to make bool Do The Right Thing in these situations myself :(
dito
Same problem occurred with "menuconfig NET_PCMCIA".
See http://marc.info/?l=linux-kernel&m=118244569131373
Regards,
Andreas
--
Operating | AMD Saxony Limited Liability Company & Co. KG,
System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Research | Register Court Dresden: HRA 4896, General Partner authorized
Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US)
(OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
>
> Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
> > Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster:
> > > Right, but IMHO this issue is typical for a problem with the Kconfig definitions of this module.
> > >
> > > I'll set USB devs as Cc: therefore.
There is too little context here, what was the exact error?
I'm assuming it's the module vs. builtin problem?
> In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS,
> that depends, in turn, on USB. So, if USB is not selected,
> V4L_USB_DRIVERS should be unselected, unselecting zc0301.
>
> Unfortunately, the Kernel building system is not properly handling it.
>
> This is the (snipped) media/video/Kconfig:
>
> menuconfig V4L_USB_DRIVERS
> bool "V4L USB devices"
> depends on USB
> default y
>
The menuconfig patches were a little aggressive here, it created a config
symbol where there was none before and in this case it even changed
dependencies (it turns USB into a bool).
I'm also a little irritated by the "default y", if I enable V4L I'm very
tempted to check what other useless stuff has been automatically enabled,
which I have to turn off again.
bye, Roman
Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
> On Jun 22 2007 15:46, Andreas Herrmann wrote:
> >Hi,
> >
> >I am not sure whether it is related or not
> >But if you select USB as module but build your v4l_usb driver
> >into the kernel you also get compile errors.
> >Attached is a patch which will prevent this by changing the menuconfig
> >from bool to tristate.
> A config option that is not referenced in the Makefile...
> should it really be a tristate? In my opinion, changing it
> to tristate is just a workaround, but I don't know kconfig
> well enough to make bool Do The Right Thing in these situations myself :(
If USB is built as a module, the V4L USB modules should also be built as
a module. Otherwise, you will have compile errors, since some required
symbols on the drivers won't be linked into the kernel.
--
Cheers,
Mauro
On Jun 22 2007 16:27, Roman Zippel wrote:
>
>> In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS,
>> that depends, in turn, on USB. So, if USB is not selected,
>> V4L_USB_DRIVERS should be unselected, unselecting zc0301.
>>
>> Unfortunately, the Kernel building system is not properly handling it.
>>
>> This is the (snipped) media/video/Kconfig:
>>
>> menuconfig V4L_USB_DRIVERS
>> bool "V4L USB devices"
>> depends on USB
>> default y
>>
>
>The menuconfig patches were a little aggressive here, it created a config
>symbol where there was none before and in this case it even changed
>dependencies (it turns USB into a bool).
V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the "this
depends on another symbol [USB] that is modular".
>I'm also a little irritated by the "default y", if I enable V4L I'm very
>tempted to check what other useless stuff has been automatically enabled,
>which I have to turn off again.
The default y only applies to the "menu" folders, not actual code.
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.
Thanks,
Jan
--
Em Sex, 2007-06-22 às 16:27 +0200, Roman Zippel escreveu:
> Hi,
>
> On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
>
> > Hi Roman,
> >
> > Several instabilities on Kconfig started to happen after replacing
> > Kconfig menus to use menuconfig, as this one, reported by Oliver:
> >
> > Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
> > > Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster:
> > > > Right, but IMHO this issue is typical for a problem with the Kconfig definitions of this module.
> > > >
> > > > I'll set USB devs as Cc: therefore.
>
> There is too little context here, what was the exact error?
> I'm assuming it's the module vs. builtin problem?
I also got copied on this without the full context.
> The menuconfig patches were a little aggressive here, it created a config
> symbol where there was none before and in this case it even changed
> dependencies (it turns USB into a bool).
Hmm... Probably the change from tristate to bool caused the regression.
> I'm also a little irritated by the "default y", if I enable V4L I'm very
> tempted to check what other useless stuff has been automatically enabled,
> which I have to turn off again.
The added "default y" are the ones bellow:
menuconfig VIDEO_CAPTURE_DRIVERS
bool "Video capture adapters"
depends on VIDEO_DEV
default y
menuconfig V4L_USB_DRIVERS
bool "V4L USB devices"
depends on USB
default y
menuconfig RADIO_ADAPTERS
bool "Radio Adapters"
depends on VIDEO_DEV
default y
menuconfig DVB_CAPTURE_DRIVERS
bool "DVB/ATSC adapters"
depends on DVB_CORE
default y
config DAB
boolean "DAB adapters"
default y
All of them are used just to open a submenu.
I'm to keep "default y" for the menuconfig items.
Since those don't generate any code (there's no Makefile items
associated with the menuconfig vars), this will just improve the
usability for the final user (and will allow make oldconfig to work).
There's not much sense on selecting V4L support without selecting a V4L
driver.
Cheers,
Mauro
On Fri, Jun 22, 2007 at 12:03:19PM -0300, Mauro Carvalho Chehab wrote:
> Em Sex, 2007-06-22 ?s 15:51 +0200, Jan Engelhardt escreveu:
> > On Jun 22 2007 15:46, Andreas Herrmann wrote:
> > >Hi,
> > >
> > >I am not sure whether it is related or not
> > >But if you select USB as module but build your v4l_usb driver
> > >into the kernel you also get compile errors.
> > >Attached is a patch which will prevent this by changing the menuconfig
> > >from bool to tristate.
>
>
> > A config option that is not referenced in the Makefile...
> > should it really be a tristate? In my opinion, changing it
> > to tristate is just a workaround, but I don't know kconfig
> > well enough to make bool Do The Right Thing in these situations myself :(
>
> If USB is built as a module, the V4L USB modules should also be built as
> a module. Otherwise, you will have compile errors, since some required
> symbols on the drivers won't be linked into the kernel.
>
Sure.
And the patch should prevent user selection of such
a broken kernel configuration.
Regards,
Andreas
--
Operating | AMD Saxony Limited Liability Company & Co. KG,
System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Research | Register Court Dresden: HRA 4896, General Partner authorized
Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US)
(OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
Am Freitag, 22. Juni 2007 schrieb Mauro Carvalho Chehab:
> Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
> > On Jun 22 2007 15:46, Andreas Herrmann wrote:
> > >Hi,
> > >
> > >I am not sure whether it is related or not
> > >But if you select USB as module but build your v4l_usb driver
> > >into the kernel you also get compile errors.
> > >Attached is a patch which will prevent this by changing the menuconfig
> > >from bool to tristate.
>
>
> > A config option that is not referenced in the Makefile...
> > should it really be a tristate? In my opinion, changing it
> > to tristate is just a workaround, but I don't know kconfig
> > well enough to make bool Do The Right Thing in these situations myself :(
>
> If USB is built as a module, the V4L USB modules should also be built as
> a module. Otherwise, you will have compile errors, since some required
> symbols on the drivers won't be linked into the kernel.
Yes, and if you build USB statically, you can build the video drivers
statically or as modules. The config language must reflect that. I
don't it is possible to represent that with a bool.
Regards
Oliver
Hi,
On Fri, 22 Jun 2007, Jan Engelhardt wrote:
> V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the "this
> depends on another symbol [USB] that is modular".
That's not how it works, the enclosed symbols depend now on
V4L_USB_DRIVERS, which is a boolean and it can only have two states.
It doesn't matter on what V4L_USB_DRIVERS depends only the final value
matters.
(BTW if check the dependency debug output in menuconfig/xconfig, you'll
see which values are relevant in the calculation of a symbol value.)
> >I'm also a little irritated by the "default y", if I enable V4L I'm very
> >tempted to check what other useless stuff has been automatically enabled,
> >which I have to turn off again.
>
> The default y only applies to the "menu" folders, not actual code.
I don't know that without checking the Makefile.
> 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.
bye, Roman
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> I'm to keep "default y" for the menuconfig items.
>
> Since those don't generate any code (there's no Makefile items
> associated with the menuconfig vars),
I don't know that without checking Makefiles/sources, so I have to assume
it may produce some infrastructure code I don't need.
> this will just improve the
> usability for the final user (and will allow make oldconfig to work).
I'd rather change that.
> There's not much sense on selecting V4L support without selecting a V4L
> driver.
But if only want to enable a video driver, I likely don't want a radio
driver...
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off-by: Roman Zippel <[email protected]>
---
scripts/kconfig/confdata.c | 37 ++++++++++++++++++++++++++-----------
1 file changed, 26 insertions(+), 11 deletions(-)
Index: linux-2.6/scripts/kconfig/confdata.c
===================================================================
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -341,27 +341,42 @@ int conf_read(const char *name)
conf_unsaved++;
/* maybe print value in verbose mode... */
sym_ok:
+ if (!sym_is_choice(sym))
+ continue;
+ /* The choice symbol only has a set value (and thus is not new)
+ * if all its visible childs have values.
+ */
+ prop = sym_get_choice_prop(sym);
+ flags = sym->flags;
+ for (e = prop->expr; e; e = e->left.expr)
+ if (e->right.sym->visible != no)
+ flags &= e->right.sym->flags;
+ sym->flags &= flags | ~SYMBOL_DEF_USER;
+ }
+
+ for_all_symbols(i, sym) {
if (sym_has_value(sym) && !sym_is_choice_value(sym)) {
- if (sym->visible == no)
+ /* Reset values of generates values, so they'll appear
+ * as new, if they should become visible, but that
+ * doesn't quite work if the Kconfig and the saved
+ * configuration disagrees.
+ */
+ if (sym->visible == no && !conf_unsaved)
sym->flags &= ~SYMBOL_DEF_USER;
switch (sym->type) {
case S_STRING:
case S_INT:
case S_HEX:
- if (!sym_string_within_range(sym, sym->def[S_DEF_USER].val))
- sym->flags &= ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ /* Reset a string value if it's out of range */
+ if (sym_string_within_range(sym, sym->def[S_DEF_USER].val))
+ break;
+ sym->flags &= ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ conf_unsaved++;
+ break;
default:
break;
}
}
- if (!sym_is_choice(sym))
- continue;
- prop = sym_get_choice_prop(sym);
- flags = sym->flags;
- for (e = prop->expr; e; e = e->left.expr)
- if (e->right.sym->visible != no)
- flags &= e->right.sym->flags;
- sym->flags &= flags | ~SYMBOL_DEF_USER;
}
sym_add_change_count(conf_warnings || conf_unsaved);
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.
Jan
--
Hi Jan,
On 6/22/07, Jan Engelhardt <[email protected]> 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.
Satyam
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
This is the same problem I explained before:
http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2007-May/004121.html
What you have is tristate depends on bool depends on tristate. The bool
between the two tristates "promotes" the first tristate from m to y.
> In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS,
> that depends, in turn, on USB. So, if USB is not selected,
> V4L_USB_DRIVERS should be unselected, unselecting zc0301.
If you set USB=n, then you can not turn on V4L_USB_DRIVERS and in turn
USB_ZC0301 can't be turned on. That does work correctly.
The problem is that if USB=m, then because V4L_USB_DRIVERS is a bool, it is
possible to set V4L_USB_DRIVERS=y. Now you can set USB_ZC0301=y, because
USB_ZC0301 only depends on V4L_USB_DRIVERS and that is 'y'. So you end up
with USB=m and USB_ZC0301=y, which shouldn't be allowed.
There are two easy solutions to this that I can think of. First,
just make the menuconfig a tristate:
diff -r dfbe7cc4e21e drivers/media/video/Kconfig
--- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700
+++ b/drivers/media/video/Kconfig Fri Jun 22 13:14:29 2007 -0700
@@ -687,7 +687,7 @@ config VIDEO_CAFE_CCIC
#
menuconfig V4L_USB_DRIVERS
- bool "V4L USB devices"
+ tristate "V4L USB devices"
depends on USB
default y
Now the menuconfig entry will be a tristate, which seems kind of odd. If
USB=m, then you won't be able to set V4L_USB_DRIVERS to 'y', only to 'n' or
'm', and in turn none of the USB devices can be set to 'y'.
Or another way, add the dependencies of the menuconfig to the if statement:
diff -r dfbe7cc4e21e drivers/media/video/Kconfig
--- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700
+++ b/drivers/media/video/Kconfig Fri Jun 22 13:10:43 2007 -0700
@@ -691,7 +691,7 @@ menuconfig V4L_USB_DRIVERS
depends on USB
default y
-if V4L_USB_DRIVERS
+if V4L_USB_DRIVERS && USB
source "drivers/media/video/pvrusb2/Kconfig"
Now all the usb drivers will gain USB as a dependency directly and can't be
set to something higher than USB.
On 6/23/07, Satyam Sharma <[email protected]> wrote:
> Hi Jan,
>
> On 6/22/07, Jan Engelhardt <[email protected]> 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
Hi Trent,
On 6/23/07, Trent Piepho <[email protected]> wrote:
> [...]
> What you have is tristate depends on bool depends on tristate. The bool
> between the two tristates "promotes" the first tristate from m to y.
> [...]
> Or another way, add the dependencies of the menuconfig to the if statement:
> diff -r dfbe7cc4e21e drivers/media/video/Kconfig
> --- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700
> +++ b/drivers/media/video/Kconfig Fri Jun 22 13:10:43 2007 -0700
> @@ -691,7 +691,7 @@ menuconfig V4L_USB_DRIVERS
> depends on USB
> default y
>
> -if V4L_USB_DRIVERS
> +if V4L_USB_DRIVERS && USB
>
> source "drivers/media/video/pvrusb2/Kconfig"
>
> Now all the usb drivers will gain USB as a dependency directly and can't be
> set to something higher than USB.
Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-)
But I still prefer 2.(b) -- making the config scripts intelligent so that if a
given "menuconfig FOO depends on BAR", then all the "config BAZ"s
inside this menuconfig also automatically "depend on" BAR too.
This is simpler in the long run because it requires least amount
(actually none) of redundant typing and would continue to work in
the future if/when the:
menuconfig FOO
if FOO
...
endif # FOO
idiom is converted to an:
configmenu FOO
...
endconfigmenu # FOO
kind of idiom ...
Satyam
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
> This is simpler in the long run because it requires least amount
> (actually none) of redundant typing
I don't like this, as this would attach special meaning to a menuconfig.
menuconfig is really a type of config symbol, rather than a type of menu.
Potentially this could also be written as:
config FOO
option menu
...
bye, Roman
Hi Roman,
On 6/23/07, Roman Zippel <[email protected]> wrote:
> Hi,
>
> On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
> > given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> > inside this menuconfig also automatically "depend on" BAR too.
> > This is simpler in the long run because it requires least amount
> > (actually none) of redundant typing
>
> I don't like this, as this would attach special meaning to a menuconfig.
But "menuconfig" _is_ special ...
> menuconfig is really a type of config symbol, rather than a type of menu.
Well, I'd have to disagree here. A config symbol has code associated
with it (at least _all_ config symbols in the kernel originally did, till
when these "menuconfig" things got introduced, which is precisely
what made them "special").
These "menuconfig" things are (or were supposed to be, at least :-)
just a _presentation_ thing.
> Potentially this could also be written as:
>
> config FOO
> option menu
> ...
I'm not sure why anybody would prefer such a syntax / idiom.
I know that "de gustibus non est disputandum", but personally
I find such usage *horribly* unclear.
Satyam
On Jun 23 2007 02:50, Satyam Sharma wrote:
>
> Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-)
>
> But I still prefer 2.(b) -- making the config scripts intelligent so that if a
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
> This is simpler in the long run because it requires least amount
> (actually none) of redundant typing and would continue to work in
> the future if/when the:
>
> menuconfig FOO
> if FOO
> ...
> endif # FOO
>
> idiom is converted to an:
>
> configmenu FOO
> ...
> endconfigmenu # FOO
>
> kind of idiom ...
Of course *this* *is* *the preferred* thing. (I think even Sam liked that one
better than the current menuconfig menuconfig confusion.) But, as always, you
need someone to code it, etc.
Jan
--
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> > menuconfig is really a type of config symbol, rather than a type of menu.
>
> Well, I'd have to disagree here. A config symbol has code associated
> with it (at least _all_ config symbols in the kernel originally did, till
> when these "menuconfig" things got introduced, which is precisely
> what made them "special").
Only because it's currently used mostly like this, it doesn't add any
"special" meaning.
bye, Roman
Hi Roman,
On 6/23/07, Roman Zippel <[email protected]> wrote:
> On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
> > > menuconfig is really a type of config symbol, rather than a type of menu.
> >
> > Well, I'd have to disagree here. A config symbol has code associated
> > with it (at least _all_ config symbols in the kernel originally did, till
> > when these "menuconfig" things got introduced, which is precisely
> > what made them "special").
>
> Only because it's currently used mostly like this, it doesn't add any
> "special" meaning.
But this will always be true (not just currently):
1. Kconfig symbols will always have code associated with them.
That's the entire purpose of Kconfig, is it not?
2. "menuconfig" symbols, otoh, were _invented_ for another reason
entirely: presentation and user interface i.e. so that users are able
to disable entire menus (and all the options contained therein)
without having to enter into the menu first, and without having to
disable all options individually (which was the situation that existed
before the introduction of these menuconfig objects).
The fact that these menuconfig objects are similar to "config symbols"
is only because of the way they got implemented, and has nothing to
do with their original purpose or the problem they try to solve.
Satyam
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> 1. Kconfig symbols will always have code associated with them.
> That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little misplaced).
It's optional for any config symbol to have any code attached to it,
menuconfig doesn't change anything.
> 2. "menuconfig" symbols, otoh, were _invented_ for another reason
> entirely: presentation and user interface i.e. so that users are able
> to disable entire menus (and all the options contained therein)
> without having to enter into the menu first, and without having to
> disable all options individually (which was the situation that existed
> before the introduction of these menuconfig objects).
Since I'm the one who _invented_ it, I can tell you you're wrong. :)
This functionality isn't limited to menuconfig symbols. The menu option
simply changes how the child symbols can be displayed.
bye, Roman
Hi,
On 6/23/07, Roman Zippel <[email protected]> wrote:
> On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
> > 1. Kconfig symbols will always have code associated with them.
> > That's the entire purpose of Kconfig, is it not?
>
> A possible counter example: CONFIG_SCSI.
> (RAID_ATTRS is currently a little misplaced).
> It's optional for any config symbol to have any code attached to it,
> menuconfig doesn't change anything.
CONFIG_SCSI _does_ have code associated with it.
(so does CONFIG_RAID_ATTRS)
[ I was expecting you to give the counter-example of various
config symbols that control the assignment of some value to
some variable, actually, but then I would've countered back
with the fact that a variable is also "code" and not something
that is only about presentation / user interface :-) ]
> > 2. "menuconfig" symbols, otoh, were _invented_ for another reason
> > entirely: presentation and user interface i.e. so that users are able
> > to disable entire menus (and all the options contained therein)
> > without having to enter into the menu first, and without having to
> > disable all options individually (which was the situation that existed
> > before the introduction of these menuconfig objects).
>
> Since I'm the one who _invented_ it, I can tell you you're wrong. :)
> This functionality isn't limited to menuconfig symbols. The menu option
> simply changes how the child symbols can be displayed.
Yup, so how / why am I wrong? I was making the point that a
"menuconfig" does not have code associated with it. Why else
_was_ it invented then, if not only for presentation / user interface
purposes? I really don't see what role it plays as a "config symbol"
in Kconfig (other than the fact that that is how it got implemented
to do its thing).
Satyam
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> Yup, so how / why am I wrong? I was making the point that a
> "menuconfig" does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
bye, Roman
Hi,
On 6/23/07, Roman Zippel <[email protected]> wrote:
> Hi,
>
> On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
> > Yup, so how / why am I wrong? I was making the point that a
> > "menuconfig" does not have code associated with it.
>
> Which is wrong, it's not and will not be limited to this.
But why? Let it do just one thing, and do it well. Is their
any requirement anywhere that requires us to give a dual
meaning to these menuconfig objects -- i.e. to also control
the inclusion / exclusion of code from the kernel as well as
also for the presentation + user interface purpose that it
currently serves?
Satyam
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> But why? Let it do just one thing, and do it well. Is their
> any requirement anywhere that requires us to give a dual
> meaning to these menuconfig objects -- i.e. to also control
> the inclusion / exclusion of code from the kernel as well as
> also for the presentation + user interface purpose that it
> currently serves?
This getting ridiculous. :-(
You're the one who is attaching a new meaning to it.
Any config symbol has multiple meanings depending on the context, the menu
property only changes _one_ of them, you want to drastically redefine it
and that's not going to happen.
bye, Roman
On Jun 23 2007 02:26, Roman Zippel wrote:
>On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
>> But why? Let it do just one thing, and do it well. Is their
>> any requirement anywhere that requires us to give a dual
>> meaning to these menuconfig objects -- i.e. to also control
>> the inclusion / exclusion of code from the kernel as well as
>> also for the presentation + user interface purpose that it
>> currently serves?
>
>This getting ridiculous. :-(
>You're the one who is attaching a new meaning to it.
>Any config symbol has multiple meanings depending on the context, the menu
>property only changes _one_ of them, you want to drastically redefine it
>and that's not going to happen.
Would it make sense to define a new entity called "configmenu" (or something
else) that is equivalent to menuconfig with the following changes?
* it creates a CM_ variable instead of a CONFIG_ one
* the CM_ symbols are not available to Makefiles or C files
(so in fact, just to menuconfig and that they are listed in .config)
Jan
--
Anyone with strong objections to this patch? (Hopefully) fixes the
kconfig issue for now.
Signed-off-by: Jan Engelhardt <[email protected]>
diff --git a/drivers/atm/Kconfig b/drivers/atm/Kconfig
index f5a47a4..d340ebb 100644
--- a/drivers/atm/Kconfig
+++ b/drivers/atm/Kconfig
@@ -3,9 +3,8 @@
#
menuconfig ATM_DRIVERS
- bool "ATM drivers"
+ tristate "ATM drivers"
depends on NETDEVICES && ATM
- default y
if ATM_DRIVERS
diff --git a/drivers/media/dvb/Kconfig b/drivers/media/dvb/Kconfig
index efd2b74..19ea410 100644
--- a/drivers/media/dvb/Kconfig
+++ b/drivers/media/dvb/Kconfig
@@ -5,7 +5,7 @@
source "drivers/media/dvb/dvb-core/Kconfig"
menuconfig DVB_CAPTURE_DRIVERS
- bool "DVB/ATSC adapters"
+ tristate "DVB/ATSC adapters"
depends on DVB_CORE
default y
---help---
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index a6ac82a..cd8c891 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig RADIO_ADAPTERS
- bool "Radio Adapters"
+ tristate "Radio Adapters"
depends on VIDEO_DEV
default y
---help---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 7d57f4a..d888cfb 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1899,9 +1899,8 @@ endmenu
#
menuconfig NETDEV_1000
- bool "Ethernet (1000 Mbit)"
+ tristate "Ethernet (1000 Mbit)"
depends on !UML
- default y
if NETDEV_1000
@@ -2337,9 +2336,8 @@ endif # NETDEV_1000
#
menuconfig NETDEV_10000
- bool "Ethernet (10000 Mbit)"
+ tristate "Ethernet (10000 Mbit)"
depends on !UML
- default y
if NETDEV_10000
diff --git a/drivers/net/pcmcia/Kconfig b/drivers/net/pcmcia/Kconfig
index 5d658bc..37369ec 100644
--- a/drivers/net/pcmcia/Kconfig
+++ b/drivers/net/pcmcia/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig NET_PCMCIA
- bool "PCMCIA network device support"
+ tristate "PCMCIA network device support"
depends on PCMCIA
---help---
Say Y if you would like to include support for any PCMCIA or CardBus
* Newsgroups: linux.kernel,comp.video.video4linux,linux.usb.devel
As you might know, there's no organized central traking system, thus
this huge lists of MLs...
> But, as always, you need someone to code it, etc.
... and no relevant one, where somebody can actually see the problem
and/or to code it. Please, care to add <[email protected]>
next time.
> On Jun 23 2007 02:50, Satyam Sharma wrote:
>>
[]
>> menuconfig FOO
>> if FOO
>> ...
>> endif # FOO
>>
>> idiom is converted to an:
>>
>> configmenu FOO
>> ...
>> endconfigmenu # FOO
>>
>> kind of idiom ...
Bah, i can't believe. Guys, are you serious about not converting
everything in to XML ?:)
____
Hi Jan,
Your patch seems OK to me, providing that we also add the Andreas patch:
---
Correct Kconfig to avoid compile errors like
drivers/built-in.o: In function `sn9c102_usb_disconnect':
sn9c102_core.c:(.text+0x8d840): undefined reference to `usb_get_dev'
Signed-off-by: Andreas Herrmann <[email protected]>
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4cca551..4754d98 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -687,7 +687,7 @@ config VIDEO_CAFE_CCIC
#
menuconfig V4L_USB_DRIVERS
- bool "V4L USB devices"
+ tristate "V4L USB devices"
depends on USB
default y
Em Sáb, 2007-06-23 às 09:20 +0200, Jan Engelhardt escreveu:
> Anyone with strong objections to this patch? (Hopefully) fixes the
> kconfig issue for now.
>
>
> Signed-off-by: Jan Engelhardt <[email protected]>
Acked-by: Mauro Carvalho Chehab <[email protected]>
(for both Andreas and your patch)
--
Cheers,
Mauro
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> On 6/23/07, Trent Piepho <[email protected]> wrote:
> > [...]
> > What you have is tristate depends on bool depends on tristate. The bool
> > between the two tristates "promotes" the first tristate from m to y.
> > [...]
> > Or another way, add the dependencies of the menuconfig to the if statement:
> > diff -r dfbe7cc4e21e drivers/media/video/Kconfig
> > --- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700
> > +++ b/drivers/media/video/Kconfig Fri Jun 22 13:10:43 2007 -0700
> > @@ -691,7 +691,7 @@ menuconfig V4L_USB_DRIVERS
> > depends on USB
> > default y
> >
> > -if V4L_USB_DRIVERS
> > +if V4L_USB_DRIVERS && USB
> >
> > source "drivers/media/video/pvrusb2/Kconfig"
> >
> > Now all the usb drivers will gain USB as a dependency directly and can't be
> > set to something higher than USB.
>
> Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-)
>
> But I still prefer 2.(b) -- making the config scripts intelligent so that if a
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
Of course, there currently is no "inside" a menuconfig. You would have to do
something like make everything inside an "if FOO / endif" gain not just a
dependency on FOO, but also gain a dependency on all of FOO's dependencies.
> This is simpler in the long run because it requires least amount
> (actually none) of redundant typing and would continue to work in
> the future if/when the:
>
> menuconfig FOO
> if FOO
> ...
> endif # FOO
>
> idiom is converted to an:
>
> configmenu FOO
> ...
> endconfigmenu # FOO
>
> kind of idiom ...
Like that I suggested here?
http://article.gmane.org/gmane.linux.kernel/524823
Basically, make menuconfig work like menu does, except the menu itself can be
turned on and off. Instead of having menuconfig work like a config, but with
some kind of "menu" hint. It seems like the former is more in line with what
menuconfig is actually used for.
On Sat, 23 Jun 2007, Mauro Carvalho Chehab wrote:
> Your patch seems OK to me, providing that we also add the Andreas patch:
>--- a/drivers/net/Kconfig
>+++ b/drivers/net/Kconfig
>menuconfig NETDEV_1000
>- bool "Ethernet (1000 Mbit)"
>+ tristate "Ethernet (1000 Mbit)"
> depends on !UML
>- default y
>
> menuconfig NETDEV_10000
>- bool "Ethernet (10000 Mbit)"
>+ tristate "Ethernet (10000 Mbit)"
> depends on !UML
>- default y
I don't think this part is necessary. The only thing NETDEV_1000[0]
depend on is UML, which is a boolean.
Here is an alternate patch for this issue. I fix it by adding the
dependencies of the menuconfig to the "if / endif" block the menuconfig
controls. That way the menu doesn't turn into a tristate, which doesn't
make a lot of sense. How can the menu be compiled as a module, when there
is no code associated with it?
------------------------------------------------------------------
Fix Kconfig dependency problems wrt boolean menuconfigs
If one has a dependency chain (tristate)FOO depends on (bool)BAR depends on
(tristate)BAZ, build problems will result. If BAZ=m, then BAR can be set y,
which allows FOO=y. It's possible to have FOO=y && BAZ=m, which wouldn't be
allowed if FOO depended directly on BAZ. In effect, the bool promotes the
tristate from m to y.
This ends up causing a problem with several menuconfigs that look like:
menuconfig BAR
bool
depends on BAZ [tristate]
if BAR
config FOO
tristate
endif
The solution used here is to add the dependencies of BAR to the if statement,
so that items in the if block will gain a direct non-bool-promoted dependency
on BAZ. This is how it would work if a menu was used instead of an if block.
Signed-off-by: Trent Piepho <[email protected]>
diff -r dfbe7cc4e21e drivers/atm/Kconfig
--- a/drivers/atm/Kconfig Thu Jun 21 16:02:50 2007 -0700
+++ b/drivers/atm/Kconfig Sat Jun 23 16:41:05 2007 -0700
@@ -7,7 +7,7 @@ menuconfig ATM_DRIVERS
depends on NETDEVICES && ATM
default y
-if ATM_DRIVERS
+if ATM_DRIVERS && NETDEVICES && ATM
config ATM_DUMMY
tristate "Dummy ATM driver"
diff -r dfbe7cc4e21e drivers/media/dvb/Kconfig
--- a/drivers/media/dvb/Kconfig Thu Jun 21 16:02:50 2007 -0700
+++ b/drivers/media/dvb/Kconfig Sat Jun 23 16:42:28 2007 -0700
@@ -11,7 +11,7 @@ menuconfig DVB_CAPTURE_DRIVERS
---help---
Say Y to select Digital TV adapters
-if DVB_CAPTURE_DRIVERS
+if DVB_CAPTURE_DRIVERS && DVB_CORE
comment "Supported SAA7146 based PCI Adapters"
depends on DVB_CORE && PCI && I2C
diff -r dfbe7cc4e21e drivers/media/radio/Kconfig
--- a/drivers/media/radio/Kconfig Thu Jun 21 16:02:50 2007 -0700
+++ b/drivers/media/radio/Kconfig Sat Jun 23 16:42:44 2007 -0700
@@ -9,7 +9,7 @@ menuconfig RADIO_ADAPTERS
---help---
Say Y here to enable selecting AM/FM radio adapters.
-if RADIO_ADAPTERS
+if RADIO_ADAPTERS && VIDEO_DEV
config RADIO_CADET
tristate "ADS Cadet AM/FM Tuner"
diff -r dfbe7cc4e21e drivers/media/video/Kconfig
--- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700
+++ b/drivers/media/video/Kconfig Sat Jun 23 17:10:17 2007 -0700
@@ -11,7 +11,7 @@ menuconfig VIDEO_CAPTURE_DRIVERS
webcams, analog TV, and hybrid analog/digital TV.
Some of those devices also supports FM radio.
-if VIDEO_CAPTURE_DRIVERS
+if VIDEO_CAPTURE_DRIVERS && VIDEO_DEV
config VIDEO_ADV_DEBUG
bool "Enable advanced debug functionality"
@@ -347,7 +347,7 @@ endmenu # encoder / decoder chips
config VIDEO_VIVI
tristate "Virtual Video Driver"
- depends on VIDEO_V4L2 && !SPARC32 && !SPARC64 && PCI && VIDEO_DEV
+ depends on VIDEO_V4L2 && !SPARC32 && !SPARC64 && PCI
select VIDEO_BUF
default n
---help---
@@ -691,7 +691,7 @@ menuconfig V4L_USB_DRIVERS
depends on USB
default y
-if V4L_USB_DRIVERS
+if V4L_USB_DRIVERS && USB
source "drivers/media/video/pvrusb2/Kconfig"
diff -r dfbe7cc4e21e drivers/net/pcmcia/Kconfig
--- a/drivers/net/pcmcia/Kconfig Thu Jun 21 16:02:50 2007 -0700
+++ b/drivers/net/pcmcia/Kconfig Sat Jun 23 16:45:44 2007 -0700
@@ -19,7 +19,7 @@ menuconfig NET_PCMCIA
If unsure, say N.
-if NET_PCMCIA
+if NET_PCMCIA && PCMCIA
config PCMCIA_3C589
tristate "3Com 3c589 PCMCIA support"
Hi,
On 6/24/07, Trent Piepho <[email protected]> wrote:
> On Sat, 23 Jun 2007, Satyam Sharma wrote:
> > On 6/23/07, Trent Piepho <[email protected]> wrote:
> > > [...]
> > > Now all the usb drivers will gain USB as a dependency directly and can't be
> > > set to something higher than USB.
> >
> > Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-)
> >
> > But I still prefer 2.(b) -- making the config scripts intelligent so that if a
> > given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> > inside this menuconfig also automatically "depend on" BAR too.
>
> Of course, there currently is no "inside" a menuconfig. You would have to do
> something like make everything inside an "if FOO / endif" gain not just a
> dependency on FOO, but also gain a dependency on all of FOO's dependencies.
Yes, making the config scripts do what you describe there
automagically is exactly what I meant there.
> > This is simpler in the long run because it requires least amount
> > (actually none) of redundant typing and would continue to work in
> > the future if/when the:
> > [...]
> > configmenu FOO
> > ...
> > endconfigmenu # FOO
> >
> > kind of idiom ...
>
> Like that I suggested here?
> http://article.gmane.org/gmane.linux.kernel/524823
>
> Basically, make menuconfig work like menu does, except the menu itself can be
> turned on and off. Instead of having menuconfig work like a config, but with
> some kind of "menu" hint. It seems like the former is more in line with what
> menuconfig is actually used for.
Again, we're in complete agreement here (also like what Jan
mentioned elsewhere on this thread). But then there's often
too much "suggestions" on Kconfig/Kbuild matters on lkml,
but too little code (wonder if that was what got Roman
irritated yesterday). This may be because stuff in scripts/ doesn't
quite get the kind of eyeballs kernel/ or fs/ or even drivers/ gets,
but I guess the only way to get Roman around to our view would
be start submitting patches for the solutions we're all fond of
"suggesting" :-)
Satyam
Hi,
On Sat, 23 Jun 2007, Jan Engelhardt wrote:
> Would it make sense to define a new entity called "configmenu" (or something
> else) that is equivalent to menuconfig with the following changes?
>
> * it creates a CM_ variable instead of a CONFIG_ one
> * the CM_ symbols are not available to Makefiles or C files
> (so in fact, just to menuconfig and that they are listed in .config)
I really don't understand why this should be needed in first place.
Where is the problem with using tristate? Nobody forces anyone to set it
to 'm' if you don't like it. I could also argue it easily allows me to
quickly restrict enclosed options to module status. It's just another
choice, where is that fascination coming from that it has to be an on/off
switch?
Whether the config option is visible in the Makefile and produces any
code, is completely irrelevant in this context, as the user trying to
configure the kernel has no idea of it.
bye, Roman