Hi Jan,
Em Seg, 2007-04-30 às 14:30 +0200, Jan Engelhardt escreveu:
> Change Kconfig objects from "menu, config" into "menuconfig" so
> that the user can disable the whole feature without having to
> enter the menu first.
>
> Also remove one indirection (CONFIG_DVB) that does not seem to
> be really used inside the kernel.
Hmm.. in fact, it becames harder to unselect DVB, at least on my tests.
The patch bellow solved the issue. It also allows keeping core DVB,
disabling the adapters menu.
If nobody is against, I intend to apply both Jan and the patch bellow on
my tree by tomorrow.
---
Allow disabling DVB Adapters
From: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
diff -r 497b1a27357c linux/drivers/media/dvb/Kconfig
--- a/linux/drivers/media/dvb/Kconfig Wed May 02 10:11:47 2007 -0300
+++ b/linux/drivers/media/dvb/Kconfig Wed May 02 11:27:23 2007 -0300
@@ -3,6 +3,15 @@
#
source "drivers/media/dvb/dvb-core/Kconfig"
+
+menuconfig DVB_CAPTURE_DRIVERS
+ bool "DVB/ATSC adapters"
+ depends on DVB_CORE
+ default y
+ ---help---
+ Say Y to select Digital TV adapters
+
+if DVB_CAPTURE_DRIVERS
comment "Supported SAA7146 based PCI Adapters"
depends on DVB_CORE && PCI && I2C
@@ -30,3 +39,5 @@ comment "Supported DVB Frontends"
comment "Supported DVB Frontends"
depends on DVB_CORE
source "drivers/media/dvb/frontends/Kconfig"
+
+endif # DVB_CAPTURE_DRIVERS
diff -r 497b1a27357c linux/drivers/media/dvb/dvb-core/Kconfig
--- a/linux/drivers/media/dvb/dvb-core/Kconfig Wed May 02 10:11:47 2007
-0300
+++ b/linux/drivers/media/dvb/dvb-core/Kconfig Wed May 02 11:06:31 2007
-0300
@@ -1,4 +1,4 @@ menuconfig DVB_CORE
-menuconfig DVB_CORE
+config DVB_CORE
tristate "DVB for Linux"
depends on NET && INET
select CRC32
On Wed, 2 May 2007, Mauro Carvalho Chehab wrote:
> Em Seg, 2007-04-30 às 14:30 +0200, Jan Engelhardt escreveu:
> > Change Kconfig objects from "menu, config" into "menuconfig" so
> > that the user can disable the whole feature without having to
> > enter the menu first.
> >
> > Also remove one indirection (CONFIG_DVB) that does not seem to
> > be really used inside the kernel.
>
> Hmm.. in fact, it becames harder to unselect DVB, at least on my tests.
> The patch bellow solved the issue. It also allows keeping core DVB,
> disabling the adapters menu.
>
> If nobody is against, I intend to apply both Jan and the patch bellow on
> my tree by tomorrow.
The v4l-dvb build system doesn't support menuconfig yet.
I'm pretty sure stuff like:
if VIDEO_CAPTURE_DRIVERS
will not work correctly either.
On May 2 2007 14:38, Trent Piepho wrote:
>On Wed, 2 May 2007, Mauro Carvalho Chehab wrote:
>> Em Seg, 2007-04-30 às 14:30 +0200, Jan Engelhardt escreveu:
>> > Change Kconfig objects from "menu, config" into "menuconfig" so
>> > that the user can disable the whole feature without having to
>> > enter the menu first.
>> >
>> > Also remove one indirection (CONFIG_DVB) that does not seem to
>> > be really used inside the kernel.
>>
>> Hmm.. in fact, it becames harder to unselect DVB, at least on my tests.
>> The patch bellow solved the issue. It also allows keeping core DVB,
>> disabling the adapters menu.
>>
>> If nobody is against, I intend to apply both Jan and the patch bellow on
>> my tree by tomorrow.
>
>The v4l-dvb build system doesn't support menuconfig yet.
>I'm pretty sure stuff like:
>if VIDEO_CAPTURE_DRIVERS
>will not work correctly either.
Have you actually tried running `make menuconfig` ['menuconfig' works
-- unfortunate misnaming between menuconfig and menuconfig though],
and looked at Documentation/kbuild/ [explains if..endif]?
menuconfig-if-...-endif is also used in other Kconfig files, and I
did not have problems building a kernel out of it.
Jan
--
Em Qui, 2007-05-03 às 08:56 +0200, Jan Engelhardt escreveu:
> On May 2 2007 14:38, Trent Piepho wrote:
> >On Wed, 2 May 2007, Mauro Carvalho Chehab wrote:
> >> Em Seg, 2007-04-30 às 14:30 +0200, Jan Engelhardt escreveu:
> >> > Change Kconfig objects from "menu, config" into "menuconfig" so
> >> > that the user can disable the whole feature without having to
> >> > enter the menu first.
> >> >
> >> > Also remove one indirection (CONFIG_DVB) that does not seem to
> >> > be really used inside the kernel.
> >>
> >> Hmm.. in fact, it becames harder to unselect DVB, at least on my tests.
> >> The patch bellow solved the issue. It also allows keeping core DVB,
> >> disabling the adapters menu.
> >>
> >> If nobody is against, I intend to apply both Jan and the patch bellow on
> >> my tree by tomorrow.
> >
> >The v4l-dvb build system doesn't support menuconfig yet.
> >I'm pretty sure stuff like:
> >if VIDEO_CAPTURE_DRIVERS
> >will not work correctly either.
>
> Have you actually tried running `make menuconfig` ['menuconfig' works
> -- unfortunate misnaming between menuconfig and menuconfig though],
> and looked at Documentation/kbuild/ [explains if..endif]?
> menuconfig-if-...-endif is also used in other Kconfig files, and I
> did not have problems building a kernel out of it.
Trent is mentioning an out-of-tree building system to allow easier
testing of V4L/DVB patches by end users and developers and during driver
development time. The building system allows faster
compilation/linkedition during driver development, by allowing you to
use:
make menuconfig/qconfig/xconfig
inside the tree, unselecting the drivers that you're not working.
This way, our building system allows testing Kconfig menus, and properly
process Kconfig items for building drivers.
The point rised by Trent is that, currently, this is not prepared to
handle the "menuconfig" and "if/endif" tags.
However, the v4l-dvb building system shouldn't stop improvements at the
kernel building system. So, if there are any limits there, the proper
solution is to fix the issues, instead of avoiding patches that could
break it.
> Jan
--
Cheers,
Mauro
On May 3 2007 09:37, Mauro Carvalho Chehab wrote:
>Trent is mentioning an out-of-tree building system to allow easier
>testing of V4L/DVB patches by end users and developers and during driver
>development time. The building system allows faster
>compilation/linkedition during driver development, by allowing you to
>use:
> make menuconfig/qconfig/xconfig
>
>inside the tree, unselecting the drivers that you're not working.
Is that all? Because you can do
make drivers/media/video/
today and it will only build that directory (or even
drivers/media/video/foo.o) to only do that one.
>The point rised by Trent is that, currently, this is not prepared to
>handle the "menuconfig" and "if/endif" tags.
>
>However, the v4l-dvb building system shouldn't stop improvements at the
>kernel building system. So, if there are any limits there, the proper
>solution is to fix the issues, instead of avoiding patches that could
>break it.
Jan
--
Em Qui, 2007-05-03 às 14:54 +0200, Jan Engelhardt escreveu:
> On May 3 2007 09:37, Mauro Carvalho Chehab wrote:
> >Trent is mentioning an out-of-tree building system to allow easier
> >testing of V4L/DVB patches by end users and developers and during driver
> >development time. The building system allows faster
> >compilation/linkedition during driver development, by allowing you to
> >use:
> > make menuconfig/qconfig/xconfig
> >
> >inside the tree, unselecting the drivers that you're not working.
>
> Is that all? Because you can do
>
> make drivers/media/video/
>
> today and it will only build that directory (or even
> drivers/media/video/foo.o) to only do that one.
I know. Use this procedure also. This is a very nice feature for kernel
developers.
However, you cannot use this procedure at the newest kernel to generate
a foo.ko driver for an older kernel. Using the out-of-tree building
system allows to compile also against older kernel versions, helping us
to receive more feedback from end users.
This is important for V4L/DVB development, since there are a number of
normal users that just bought a new video capture board or webcam and
want to compile the newest driver, without risking on compiling the
entire kernel, and selecting several items they don't understand.
There are more than 500 different supported boards, with lots of
different variations. Probably, there are more board variations than
subscribed users at V4L ML. Believe-me, it is not easy to find people
with all those variations, asking they to replace their kernels to the
newest version, although this is the recommended way.
So, it is important to have an easy procedure for they to test V4L/DVB.
They just need to clone the tree or retrieve a tarball, and do "make;
make install" (providing that the kernel were compiled with modules
option enabled). Advanced users may also do "make menuconfig" to select
just the driver for his board. They don't need to touch on other kernel
parameters.
Anyway, Trent's wrote a fix for our building system, adding the missing
Kconfig vocabulary used on drivers/media Kconfig.
--
Cheers,
Mauro
On Thu, 3 May 2007, Jan Engelhardt wrote:
> On May 3 2007 09:37, Mauro Carvalho Chehab wrote:
> >Trent is mentioning an out-of-tree building system to allow easier
> >testing of V4L/DVB patches by end users and developers and during driver
> >development time. The building system allows faster
> >compilation/linkedition during driver development, by allowing you to
> >use:
> > make menuconfig/qconfig/xconfig
> >
> >inside the tree, unselecting the drivers that you're not working.
>
> Is that all? Because you can do
Before I bore you to death with v4l-dvb stuff, I've written something about
the "use menuconfig objects" patches at the end.
No, it's much more than that. The v4l-dvb tree at linuxtv.org is
significantly different than just a copy of linux/drivers/media.
For one thing, the v4l-dvb tree will build on kernels between 2.6.12 and the
latest git kernel. There still some support for pre 2.6 kernels too, but it's
not maintained.
This way we can ask people to download the latest hg (we use Mercurial) and
test it, without also telling them to download and compile the latest kernel
from git.
The out of tree v4l-dvb build system uses the same Kconfig/Makefiles as it
does in the kernel. This part of the kernel build system is not easily
exported to out of tree modules, so we have some scripts to handle this.
Some drivers won't work on older kernels, and we have a way to detecting this
and modifying kconfig entries to disable the driver. If someone has ISA
disabled in their kernel, or is lacking OSS header files, they can not use an
ISA radio card driver or compile an OSS tvcard sound module. On the other
hand, if someone has disabled DVB in their kernel, it's still possible to
build and use the out of tree DVB drivers. There is a perl script that
understands the kconfig language and deals with resolving kconfig dependencies
(Rather than write a kconfig expression parser and evaluator, I wrote a
kconfig expression to perl expression translator). We take care of needing to
use the kernel autoconf.h file, yet wanting to override the options set in the
out of tree v4l-dvb configuration.
> >The point rised by Trent is that, currently, this is not prepared to
> >handle the "menuconfig" and "if/endif" tags.
BTW, I've now fixed this.
Jan, have you looked at the effect these changes have when using xconfig, and
not just menuconfig?
While your changes make menuconfig better, they have nearly opposite effect on
xconfig.
xconfig has the menu tree display in the left panel, where one can see the
overall layout of the menu tree and jump directly to any menu (even one
multiple levels deep). All the menuconfigs that used to be menus don't show
up here anymore.
To turn a menuconfig off, you must go to the top level menu containing the
menuconfig you want (and you must know which one that is!). Then you have to
drill down through each menu level one by one, by finding that menu in the top
panel (which also has all the config options listed) and clicking on it to get
to the next one. When you get to the menuconfig you want, you must enter it
and then you finally get the box to turn that menuconfig off.
It looks like your changes are going in, so I suppose the solution is to
improve the way xconfig handles "menuconfig".
I wonder, would it be possible to change the kconfig language so that:
menuconfig XXXX
boolean "name of menu"
Did the same thing as:
config XXXX
boolean "name of menu"
menu "name of menu"
depends on XXXX
This way you could change this:
menuconfig XXXX
if XXXX
[....all the other options....]
endif
Into this:
menuconfig XXXX
[....all the other options....]
endmenu
The reason is that a frontend would easily be able to understand the coupling
between the "menuconfig XXXX" and the "if XXXX". It will make it easier for
the frontend to see that all the options are inside and controlled by the
enclosing menuconfig.
Please include Roman Zippel when you propose kconfig changes.
Sam
>
> Jan, have you looked at the effect these changes have when using xconfig, and
> not just menuconfig?
>
> While your changes make menuconfig better, they have nearly opposite effect on
> xconfig.
>
> xconfig has the menu tree display in the left panel, where one can see the
> overall layout of the menu tree and jump directly to any menu (even one
> multiple levels deep). All the menuconfigs that used to be menus don't show
> up here anymore.
>
> To turn a menuconfig off, you must go to the top level menu containing the
> menuconfig you want (and you must know which one that is!). Then you have to
> drill down through each menu level one by one, by finding that menu in the top
> panel (which also has all the config options listed) and clicking on it to get
> to the next one. When you get to the menuconfig you want, you must enter it
> and then you finally get the box to turn that menuconfig off.
>
> It looks like your changes are going in, so I suppose the solution is to
> improve the way xconfig handles "menuconfig".
>
> I wonder, would it be possible to change the kconfig language so that:
> menuconfig XXXX
> boolean "name of menu"
>
> Did the same thing as:
> config XXXX
> boolean "name of menu"
> menu "name of menu"
> depends on XXXX
>
> This way you could change this:
>
> menuconfig XXXX
> if XXXX
> [....all the other options....]
> endif
>
> Into this:
>
> menuconfig XXXX
> [....all the other options....]
> endmenu
>
> The reason is that a frontend would easily be able to understand the coupling
> between the "menuconfig XXXX" and the "if XXXX". It will make it easier for
> the frontend to see that all the options are inside and controlled by the
> enclosing menuconfig.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> The out of tree v4l-dvb build system uses the same Kconfig/Makefiles as it
> does in the kernel. This part of the kernel build system is not easily
> exported to out of tree modules, so we have some scripts to handle this.
Can you elaborate of what was causing your troubles.
Maybe kbuild/kconfig can be improved in this respect..
Sam
On May 3 2007 13:39, Trent Piepho wrote:
>
>> >The point rised by Trent is that, currently, this is not prepared to
>> >handle the "menuconfig" and "if/endif" tags.
>
>BTW, I've now fixed this.
>
>Jan, have you looked at the effect these changes have when using xconfig, and
>not just menuconfig?
"The mouse is used to point at the xterm you want to type in."
So, sorry, no, I did not. However, Stefan notes his experience
with some earlier patches with [xg]config:
http://lkml.org/lkml/2007/4/10/326
For you, I installed qt3-devel/libglade2-devel on my machine
and ran it in [xg]config.
>While your changes make menuconfig better, they have nearly opposite effect on
>xconfig.
>
>xconfig has the menu tree display in the left panel, where one can see the
>overall layout of the menu tree and jump directly to any menu (even one
>multiple levels deep). All the menuconfigs that used to be menus don't show
>up here anymore.
That seems very much like a bug^Wmissing feature in [xg]config's
"Split View". It does work in Single View and Tree View.
>It looks like your changes are going in, so I suppose the solution is to
>improve the way xconfig handles "menuconfig".
>[...]
>The reason is that a frontend would easily be able to understand the coupling
>between the "menuconfig XXXX" and the "if XXXX". It will make it easier for
>the frontend to see that all the options are inside and controlled by the
>enclosing menuconfig.
It works a bit different than 'menu'. An object will be put into a
menuconfig-menu IFF it has a depends on the menuconfig item.
This is different from menu-menus, which have "sort of" an
implicit "if/endif" block.
Jan
--
Hi,
On Thu, 3 May 2007, Sam Ravnborg wrote:
> Please include Roman Zippel when you propose kconfig changes.
Thanks, the lkml volume lately forces me to skip a lot, so it's quite
possible I miss something. :)
> > xconfig has the menu tree display in the left panel, where one can see the
> > overall layout of the menu tree and jump directly to any menu (even one
> > multiple levels deep). All the menuconfigs that used to be menus don't show
> > up here anymore.
> >
> > To turn a menuconfig off, you must go to the top level menu containing the
> > menuconfig you want (and you must know which one that is!). Then you have to
> > drill down through each menu level one by one, by finding that menu in the top
> > panel (which also has all the config options listed) and clicking on it to get
> > to the next one. When you get to the menuconfig you want, you must enter it
> > and then you finally get the box to turn that menuconfig off.
> >
> > It looks like your changes are going in, so I suppose the solution is to
> > improve the way xconfig handles "menuconfig".
I don't quite understand. With the menuconfig changes more menu entries
should appear on the left side, so I don't understand why you have to
"drill down" to reach it.
The rule for menu to appear on the left side is relatively simple - all
its parents must be of menu type as well. So if a menuconfig is on the
right side it must have a normal config entry as parent.
> > I wonder, would it be possible to change the kconfig language so that:
> > menuconfig XXXX
> > boolean "name of menu"
> >
> > Did the same thing as:
> > config XXXX
> > boolean "name of menu"
> > menu "name of menu"
> > depends on XXXX
> >
> > This way you could change this:
> >
> > menuconfig XXXX
> > if XXXX
> > [....all the other options....]
> > endif
> >
> > Into this:
> >
> > menuconfig XXXX
> > [....all the other options....]
> > endmenu
> >
> > The reason is that a frontend would easily be able to understand the coupling
> > between the "menuconfig XXXX" and the "if XXXX". It will make it easier for
> > the frontend to see that all the options are inside and controlled by the
> > enclosing menuconfig.
If the frontend wants to change the behaviour of a menuconfig, it can
already do that, so this doesn't require a syntax change.
bye, Roman
On Fri, 4 May 2007, Roman Zippel wrote:
> I don't quite understand. With the menuconfig changes more menu entries
> should appear on the left side, so I don't understand why you have to
> "drill down" to reach it.
> The rule for menu to appear on the left side is relatively simple - all
> its parents must be of menu type as well. So if a menuconfig is on the
> right side it must have a normal config entry as parent.
I think that's it. The media tree was done with options to select the core
system module, then a menuconfig that depended on that which the drivers
were under.
> > > menuconfig XXXX
> > > if XXXX
> > > [....all the other options....]
> > > endif
> > >
> > > Into this:
> > >
> > > menuconfig XXXX
> > > [....all the other options....]
> > > endmenu
> > >
> > > The reason is that a frontend would easily be able to understand the coupling
> > > between the "menuconfig XXXX" and the "if XXXX". It will make it easier for
> > > the frontend to see that all the options are inside and controlled by the
> > > enclosing menuconfig.
>
> If the frontend wants to change the behaviour of a menuconfig, it can
> already do that, so this doesn't require a syntax change.
How about these examples:
menuconfig FOO
if FOO
config A
depends on FOO
endif
config B
if FOO
config C
depends on FOO
endif
Or this:
menu FOO
menuconfig BAR
config A
menuconfig BAZ
config B
endmenu
How does it show the first one, keeping the config entries in the correct
order and put them into the menu at the same time?
And which of what should the second be show?
foo
\-bar
\-baz
or
foo
|-bar
\-baz
There is no question with menus, as the menu tree is clearly lexically
defined by the matching menu / endmenu pairs. But menuconfig doesn't work
that way, and it seems like it would make more sense if it did.
On May 3 2007 18:40, Trent Piepho wrote:
>
>How about these examples:
>
>menuconfig FOO
>if FOO
>config A
> depends on FOO
>endif
>config B
>if FOO
>config C
> depends on FOO
>endif
This does not work as expected in ncurses-menuconfig either.
It does not even need a "menuconfig" object for that, something
as simple as
config A
config B
config C
depends on A
prints it
A
B
C
rather than
A
\_ C
B
which is why some of my menuconfig patches _move_ C to not come after B.
>How does it show the first one, keeping the config entries in the correct
>order and put them into the menu at the same time?
>
>And which of what should the second be show?
>
>foo
>\-bar
> \-baz
>
>or
>
>foo
>|-bar
>\-baz
>
>There is no question with menus, as the menu tree is clearly lexically
>defined by the matching menu / endmenu pairs. But menuconfig doesn't work
>that way, and it seems like it would make more sense if it did.
>
Jan
--