[PATCH 0/30] Use menuconfig objects

[PATCH 0/30] Use menuconfig objects

[Al Boldi]

Jan Engelhardt wrote:
> the following patch series turns some menus into menuconfigs, so they
> can be disabled whilst "walking" thorugh the parent menu

Great, but instead of making it a simple on/off, make it tri-state that would 
default select all child-options appropriately.  (see HW_RANDOM)


Thanks!

--
Al

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

On Apr 11 2007 01:12, Al Boldi wrote:
>Jan Engelhardt wrote:
>> the following patch series turns some menus into menuconfigs, so they
>> can be disabled whilst "walking" thorugh the parent menu
>
>Great, but instead of making it a simple on/off, make it tri-state that would 
>default select all child-options appropriately.  (see HW_RANDOM)

I do not remember having touched the Random Number Generators or Character
Devices anywhere in this series.

Don't worry, I have paid attention (or at least I hope so ;-) to 
'm'-able options, for example the SCSI, IEEE1394, or I2C stacks.

But, for example you will see
 [*] Old CD-ROM drivers (not SCSI, not IDE)

which is because this entry in itself does not generate any object file.

Generally, I just made the 'menuconfig' entry have the same state 
(bool/tristate) as the original entry. If I have overseen that 
somewhere, please let me know!


Thank you,
Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Al Boldi]

Jan Engelhardt wrote:
> On Apr 11 2007 01:12, Al Boldi wrote:
> >Jan Engelhardt wrote:
> >> the following patch series turns some menus into menuconfigs, so they
> >> can be disabled whilst "walking" thorugh the parent menu
> >
> >Great, but instead of making it a simple on/off, make it tri-state that
> > would default select all child-options appropriately.  (see HW_RANDOM)
>
> I do not remember having touched the Random Number Generators or Character
> Devices anywhere in this series.
>
> Don't worry, I have paid attention (or at least I hope so ;-) to
> 'm'-able options, for example the SCSI, IEEE1394, or I2C stacks.
>
> But, for example you will see
>  [*] Old CD-ROM drivers (not SCSI, not IDE)
>
> which is because this entry in itself does not generate any object file.
>
> Generally, I just made the 'menuconfig' entry have the same state
> (bool/tristate) as the original entry. If I have overseen that
> somewhere, please let me know!

Correct, no oversight here; but it may be more meaningful, if you could 
default select child-options based on the parent-state, like HW_RANDOM.

Also, I don't think it's necessary to touch any of the "depends on"; keep 
them as is, as they don't hurt staying that way, and may actually be 
necessary under certain circumstances.  (see EMBEDDED)


Thanks!

--
Al

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

On Apr 11 2007 07:42, Al Boldi wrote:
>Jan Engelhardt wrote:
>
>Correct, no oversight here; but it may be more meaningful, if you could 
>default select child-options based on the parent-state, like HW_RANDOM.

A symbol will already have the 'magic' you describe if its creator wrote 
it that way. Changing to 'menuconfig' tokens does not change that I 
think. Consider:

menu "foobar"
config FOOBAR
  bool "foobar"
  default y

config HW_RANDOM
  depends on FOOBAR
  default y

endmenu

This example should do things as you describe -- if FOOBAR is changed 
from n to y, HW_RANDOM should automatically do the same since it is a 
new option then.

menuconfig FOOBAR
  bool "foobar"
  default y

if FOOBAR

config HW_RANDOM
  default y

endif

inhibits the same behavior AFAICS.

>Also, I don't think it's necessary to touch any of the "depends on"; keep 
>them as is, as they don't hurt staying that way, and may actually be 
>necessary under certain circumstances.  (see EMBEDDED)

Simplifying the depends lines is a good thing IMO.


Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Stefan Richter]

Jan Engelhardt wrote:
> On Apr 11 2007 07:42, Al Boldi wrote:
>>Also, I don't think it's necessary to touch any of the "depends on"; keep 
>>them as is, as they don't hurt staying that way, and may actually be 
>>necessary under certain circumstances.  (see EMBEDDED)
> 
> Simplifying the depends lines is a good thing IMO.

If explicit dependency statements are replaced by if--endif blocks, does
this count as simplification?
-- 
Stefan Richter
-=====-=-=== -=-- -=-==
http://arcgraph.de/sr/

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

On Apr 11 2007 18:53, Stefan Richter wrote:
>Jan Engelhardt wrote:
>> On Apr 11 2007 07:42, Al Boldi wrote:
>>>Also, I don't think it's necessary to touch any of the "depends on"; keep 
>>>them as is, as they don't hurt staying that way, and may actually be 
>>>necessary under certain circumstances.  (see EMBEDDED)
>> 
>> Simplifying the depends lines is a good thing IMO.
>
>If explicit dependency statements are replaced by if--endif blocks, does
>this count as simplification?

According to Documentation/kbuild/, if FOO .. endif is interpreted as if
each option inside the if block had 'depends on FOO'.

If _every_ option under a menu (and that's another reason why I did not
modify _all_ Kconfig menus) has a 'depends on this or that', it can
be substituted by an if block, and yes, I take that as a simplification
since the whole LoC count goes down. What would perhaps be cool is
some indent in Kconfig to see what an if-endif block spans, but currently
this is not much needed, since two nested ifs are quite the max.

Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Sam Ravnborg]

On Wed, Apr 11, 2007 at 06:53:37PM +0200, Stefan Richter wrote:
> Jan Engelhardt wrote:
> > On Apr 11 2007 07:42, Al Boldi wrote:
> >>Also, I don't think it's necessary to touch any of the "depends on"; keep 
> >>them as is, as they don't hurt staying that way, and may actually be 
> >>necessary under certain circumstances.  (see EMBEDDED)
> > 
> > Simplifying the depends lines is a good thing IMO.
> 
> If explicit dependency statements are replaced by if--endif blocks, does
> this count as simplification?
Applied with some common sense - yes.
if --endif blocks has been used in several places to make dependencies consistent.
When cleaning up the net part I recall a few places where the explicit dependency
was missing causing 1) dependencies to be wrong and 2) caused indention in menu-
config to be wrong.

But yet agin do not go and replace all dependencies with if--endif blocks.
They shall be used with some good taste.


	Sam

Re: [PATCH 0/30] Use menuconfig objects

[Al Boldi]

Jan Engelhardt wrote:
> On Apr 11 2007 07:42, Al Boldi wrote:
> >Jan Engelhardt wrote:
> >
> >Correct, no oversight here; but it may be more meaningful, if you could
> >default select child-options based on the parent-state, like HW_RANDOM.
>
> A symbol will already have the 'magic' you describe if its creator wrote
> it that way. Changing to 'menuconfig' tokens does not change that I
> think. Consider:
>
> menu "foobar"
> config FOOBAR
>   bool "foobar"
>   default y
>
> config HW_RANDOM
>   depends on FOOBAR
>   default y
>
> endmenu
>
> This example should do things as you describe -- if FOOBAR is changed
> from n to y, HW_RANDOM should automatically do the same since it is a
> new option then.

I don't think so. But this might:

menu "foobar"
 config FOOBAR
   bool "foobar"
   default y

 config HW_RANDOM
   depends on FOOBAR
   default FOOBAR

endmenu

>
> menuconfig FOOBAR
>   bool "foobar"
>   default y
>
> if FOOBAR
>
> config HW_RANDOM
>   default y
>
> endif
>
> inhibits the same behavior AFAICS.

I think you mean "exhibits"?

>
> >Also, I don't think it's necessary to touch any of the "depends on"; keep
> >them as is, as they don't hurt staying that way, and may actually be
> >necessary under certain circumstances.  (see EMBEDDED)
>
> Simplifying the depends lines is a good thing IMO.

You are replacing the depends with an if block, which seems to add 
complexity, as we now have two constructs, if and depends.

IMHO, leave the depends as is, for simplicity and correctness and 
maintainability.

So if we have something like this:

menu "foobar"
 config FOOBAR
   bool "foobar"
   default y

 config FOOBAR_SUB1
   tristate "FOOBAR SUB1"
   depends on FOOBAR
   default m

 config FOOBAR_SUB2
   bool "FOOBAR SUB2"
   depends on FOOBAR
   default y

endmenu

Change it to something like this:

menuconfig FOOBAR
   tristate "foobar"
   default y

 config FOOBAR_SUB1
   tristate "FOOBAR SUB1"
   depends on FOOBAR
   default FOOBAR

 config FOOBAR_SUB2
   bool "FOOBAR SUB2"
   depends on FOOBAR
   default FOOBAR

without any if blocks, and maybe even in its own Kconfig.


Thanks!

--
Al

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

On May 10 2007 23:18, Andrew Morton wrote:
>On Fri, 11 May 2007 08:05:50 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>> On May 10 2007 15:38, Andrew Morton wrote:
>> >Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>> >
>> >> the following patch series turns some menus into menuconfigs, so they 
>> >> can be disabled whilst "walking" thorugh the parent menu (check the 
>> >> videos [1], [2] to see what I mean), enabling for disabling lots of 
>> >> options _quickly_.
>> >
>> >Well Martin's little tromp through the Kconfig menus meant that I had to
>> >repair pretty much every one of these patches.  Could you please have a
>> >look at http://userweb.kernel.org/~akpm/menuconfig/, see if I screwed
>> >anything up?

There is not much to screw. If you missed to clean a "depends on"
line, that is not problematic.

	Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Andrew Morton]

On Fri, 11 May 2007 08:05:50 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> 
> On May 10 2007 15:38, Andrew Morton wrote:
> >Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >
> >> the following patch series turns some menus into menuconfigs, so they 
> >> can be disabled whilst "walking" thorugh the parent menu (check the 
> >> videos [1], [2] to see what I mean), enabling for disabling lots of 
> >> options _quickly_.
> >
> >Well Martin's little tromp through the Kconfig menus meant that I had to
> >repair pretty much every one of these patches.  Could you please have a
> >look at http://userweb.kernel.org/~akpm/menuconfig/, see if I screwed
> >anything up?
> 
> Onto which tree/version do they apply now?
> 

mainline, mostly.  There may be slight differences due to stuff in maintainer
trees.  But all the damage was in mainline.

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

On May 10 2007 15:38, Andrew Morton wrote:
>Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
>> the following patch series turns some menus into menuconfigs, so they 
>> can be disabled whilst "walking" thorugh the parent menu (check the 
>> videos [1], [2] to see what I mean), enabling for disabling lots of 
>> options _quickly_.
>
>Well Martin's little tromp through the Kconfig menus meant that I had to
>repair pretty much every one of these patches.  Could you please have a
>look at http://userweb.kernel.org/~akpm/menuconfig/, see if I screwed
>anything up?

Onto which tree/version do they apply now?

	Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Andrew Morton]

On Tue, 10 Apr 2007 21:17:40 +0200 (MEST)
Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> the following patch series turns some menus into menuconfigs, so they 
> can be disabled whilst "walking" thorugh the parent menu (check the 
> videos [1], [2] to see what I mean), enabling for disabling lots of 
> options _quickly_.

Well Martin's little tromp through the Kconfig menus meant that I had to
repair pretty much every one of these patches.  Could you please have a
look at http://userweb.kernel.org/~akpm/menuconfig/, see if I screwed
anything up?

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

On Apr 13 2007 11:50, Jean Delvare wrote:
>
>As far as I can see, the hwmon subsystem would benefit from that too.

yeah next series...

Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Jean Delvare]

Jan,

On Tue, 10 Apr 2007 21:17:40 +0200 (MEST), Jan Engelhardt wrote:
> the following patch series turns some menus into menuconfigs, so they 
> can be disabled whilst "walking" thorugh the parent menu (check the 
> videos [1], [2] to see what I mean), enabling for disabling lots of 
> options _quickly_.
> 
> I'll send the patches (as a reply to this mail) piece by piece out
> when I figure out the maintainers to Cc for each.
> 
> [1] 6.04 MB(1000s) 70 sec http://jengelh.hopto.org/mc/without.ogg
> [2] 1.96 MB(1000s) 44 sec http://jengelh.hopto.org/mc/with.ogg

You might want to try the -q flag of quilt push and quilt pop.

> I have not poked on all subsystems (it is quite a lot), but I can 
> already give a glimpse (`ls -1`) of who gets one and who does not.
> And, I am not completely finished changing some subsystems - but
> the patches are already big enough for a first wave. I want to get
> some feedback first. Thanks!
> 
> `ls -1`:
> 	menuconfig-acpi.diff
> 	menuconfig-apm.diff
> 	menuconfig-ata.diff
> 	menuconfig-block.diff
> 	menuconfig-connector.diff
> 	menuconfig-crypto.diff
> 	menuconfig-crypto2.diff
> 	menuconfig-dccp.diff
> 	menuconfig-fusion.diff
> 	menuconfig-i2c.diff
> 	menuconfig-i2o.diff
> 	menuconfig-ide.diff
> 	menuconfig-ieee1394.diff
> 	menuconfig-md.diff
> 	menuconfig-modules.diff
> 	menuconfig-mtd.diff
> 	menuconfig-net-ipvs.diff
> 	menuconfig-net-sctp.diff
> 	menuconfig-net-tipc.diff
> 	menuconfig-netdev-arcnet.diff
> 	menuconfig-netdev-phy.diff
> 	menuconfig-netdev-tr.diff
> 	menuconfig-netdev.diff
> 	menuconfig-oldcd.diff
> 	menuconfig-parport.diff
> 	menuconfig-pcihotplug.diff
> 	menuconfig-pcmcia.diff
> 	menuconfig-pnp.diff
> 	menuconfig-scsi.diff
> 	menuconfig-w1.diff

As far as I can see, the hwmon subsystem would benefit from that too.

-- 
Jean Delvare

Re: [PATCH 0/30] Use menuconfig objects

[Andrew Morton]

On Fri, 13 Apr 2007 01:16:35 +0200 (MEST)
Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> On Apr 12 2007 15:50, Andrew Morton wrote:
> >On Tue, 10 Apr 2007 21:17:40 +0200 (MEST)
> >Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >
> >> the following patch series turns some menus into menuconfigs, so they 
> >> can be disabled whilst "walking" thorugh the parent menu
> >
> >So I merged the 23 of these which survived review and which do not
> >intersect with other outstanding work.
> >
> >I don't think I have an opinion on whether the change is actually an
> >
> >If we're going to make this change, we should ensure that it is done
> >kernel-wide, for UI consistency reasons.
> 
> If time permits, I'll go through the rest of the menus I find
> eligible for menuconfig-izing.

OK.  It's encouraging that Randy is on board.

> Does it help to base them on -mm to work better with outstanding work?

At this stage in the development cycle:

 5444 files changed, 530428 insertions(+), 179401 deletions(-)

yes, it helps quite a lot.

Re: [PATCH 0/30] Use menuconfig objects

[Randy Dunlap]

Jan Engelhardt wrote:
> Hi,
> 
> On Apr 12 2007 16:07, Randy Dunlap wrote:
>> On Thu, 12 Apr 2007 15:50:12 -0700 Andrew Morton wrote:
>>> So I merged the 23 of these which survived review and which do not
>>> intersect with other outstanding work.
>>>
>>> I don't think I have an opinion on whether the change is actually an
>>> improvement, and I don't get a clear sense of what others think.  Shrug.
>> I like them, but then I have made & sent similar patches in the past.
> 
> Would you like to go through remaining menus and make the patches?
> Just that efforts are not needlessy duplicated again. And of course
> for you to get your share if you desire so.

Hi,

I'm a bit too busy at the moment so please go ahead with it.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

Hi,

On Apr 12 2007 16:07, Randy Dunlap wrote:
>On Thu, 12 Apr 2007 15:50:12 -0700 Andrew Morton wrote:
>> 
>> So I merged the 23 of these which survived review and which do not
>> intersect with other outstanding work.
>> 
>> I don't think I have an opinion on whether the change is actually an
>> improvement, and I don't get a clear sense of what others think.  Shrug.
>
>I like them, but then I have made & sent similar patches in the past.

Would you like to go through remaining menus and make the patches?
Just that efforts are not needlessy duplicated again. And of course
for you to get your share if you desire so.


Thanks,
Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

Hi,

On Apr 12 2007 15:50, Andrew Morton wrote:
>On Tue, 10 Apr 2007 21:17:40 +0200 (MEST)
>Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
>> the following patch series turns some menus into menuconfigs, so they 
>> can be disabled whilst "walking" thorugh the parent menu
>
>So I merged the 23 of these which survived review and which do not
>intersect with other outstanding work.
>
>I don't think I have an opinion on whether the change is actually an
>
>If we're going to make this change, we should ensure that it is done
>kernel-wide, for UI consistency reasons.

If time permits, I'll go through the rest of the menus I find
eligible for menuconfig-izing.

Does it help to base them on -mm to work better with outstanding work?


Thanks,
Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Randy Dunlap]

On Thu, 12 Apr 2007 15:50:12 -0700 Andrew Morton wrote:

> On Tue, 10 Apr 2007 21:17:40 +0200 (MEST)
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > the following patch series turns some menus into menuconfigs, so they 
> > can be disabled whilst "walking" thorugh the parent menu
> 
> So I merged the 23 of these which survived review and which do not
> intersect with other outstanding work.
> 
> I don't think I have an opinion on whether the change is actually an
> improvement, and I don't get a clear sense of what others think.  Shrug.

I like them, but then I have made & sent similar patches in the past.


> If we're going to make this change, we should ensure that it is done
> kernel-wide, for UI consistency reasons.
> 
> If nothing else happens, I guess I'll spray these patches at the relevant
> maintainers in a couple of weeks time, see what sticks.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 0/30] Use menuconfig objects

[Andrew Morton]

On Tue, 10 Apr 2007 21:17:40 +0200 (MEST)
Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> the following patch series turns some menus into menuconfigs, so they 
> can be disabled whilst "walking" thorugh the parent menu

So I merged the 23 of these which survived review and which do not
intersect with other outstanding work.

I don't think I have an opinion on whether the change is actually an
improvement, and I don't get a clear sense of what others think.  Shrug.

If we're going to make this change, we should ensure that it is done
kernel-wide, for UI consistency reasons.

If nothing else happens, I guess I'll spray these patches at the relevant
maintainers in a couple of weeks time, see what sticks.

Re: [PATCH 0/30] Use menuconfig objects

[Robert P. J. Day]

On Wed, 11 Apr 2007, Adrian Bunk wrote:

> On Wed, Apr 11, 2007 at 12:09:01AM +0200, Jan Engelhardt wrote:
> >
> > On Apr 11 2007 00:04, Stefan Richter wrote:
> > >
> > >[...] I tried one of the patches
> > >  - with make xconfig: OK
> > >  - with make gconfig: OK
> > >  - with make menuconfig: less so, because:
> > >When one switches a menuconfig _on_, one might miss that there are
> > >subsequent options to configure.  (Although the availability of further
> > >options is indicated by the '--->' suffix to the menu title.)
> >
> > The kconfig files had some menuconfigs for some time
> > (CONFIG_EMBEDDED to be one). I do not think these menu entry types
> > are unknown.
>
> And the EMBEDDED menu has the interesting property that it's not
> empty with CONFIG_EMBEDDED=n .

that entire "Embedded" submenu is a hideous mis-design, as selecting
it simply presents you with options you can now "*de-select*.  that is
*anything* but intuitive.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH 0/30] Use menuconfig objects

[Adrian Bunk]

On Wed, Apr 11, 2007 at 12:09:01AM +0200, Jan Engelhardt wrote:
> 
> On Apr 11 2007 00:04, Stefan Richter wrote:
> >
> >[...] I tried one of the patches
> >  - with make xconfig: OK
> >  - with make gconfig: OK
> >  - with make menuconfig: less so, because:
> >When one switches a menuconfig _on_, one might miss that there are
> >subsequent options to configure.  (Although the availability of further
> >options is indicated by the '--->' suffix to the menu title.)
> 
> The kconfig files had some menuconfigs for some time (CONFIG_EMBEDDED to be
> one). I do not think these menu entry types are unknown.

And the EMBEDDED menu has the interesting property that it's not empty 
with CONFIG_EMBEDDED=n .

> Jan

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 0/30] Use menuconfig objects

[Stefan Richter]

David Lang wrote:
> On Wed, 11 Apr 2007, Stefan Richter wrote:
>>  - with make xconfig: OK
>>  - with make gconfig: OK
>>  - with make menuconfig: less so, because:
>> When one switches a menuconfig _on_, one might miss that there are
>> subsequent options to configure.  (Although the availability of further
>> options is indicated by the '--->' suffix to the menu title.)
> 
> I use menuconfig almost excludively, there are already quite a few cases
> where the menuconfig is used, so you already need to watch out for the
> '--->' when you turn it on.

OK.

> I haven't applied this patch series, but I definantly like the concept.
> I spend a _lot_ of time with a new kernel going through and entering
> menus for the sole purpose of disabling everything in them, being able
> to do so from the level above would be nice.
...

Actually, people who configure a kernel less than twice a year should be
first heard on these matters. :-) You won't find many of those people
here on LKML though.
-- 
Stefan Richter
-=====-=-=== -=-- -=-==
http://arcgraph.de/sr/

Re: [PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

On Apr 11 2007 00:04, Stefan Richter wrote:
>
>[...] I tried one of the patches
>  - with make xconfig: OK
>  - with make gconfig: OK
>  - with make menuconfig: less so, because:
>When one switches a menuconfig _on_, one might miss that there are
>subsequent options to configure.  (Although the availability of further
>options is indicated by the '--->' suffix to the menu title.)

The kconfig files had some menuconfigs for some time (CONFIG_EMBEDDED to be
one). I do not think these menu entry types are unknown.

Jan
-- 

Re: [PATCH 0/30] Use menuconfig objects

[Stefan Richter]

Jan Engelhardt wrote:
> the following patch series turns some menus into menuconfigs, so they 
> can be disabled whilst "walking" thorugh the parent menu (check the 
> videos [1], [2] to see what I mean), enabling for disabling lots of 
> options _quickly_.
> 
> I'll send the patches (as a reply to this mail) piece by piece out
> when I figure out the maintainers to Cc for each.
> 
> [1] 6.04 MB(1000s) 70 sec http://jengelh.hopto.org/mc/without.ogg
> [2] 1.96 MB(1000s) 44 sec http://jengelh.hopto.org/mc/with.ogg
> (Ogg container, Theora Video, no audio)
> 
> I have not poked on all subsystems (it is quite a lot), but I can 
> already give a glimpse (`ls -1`) of who gets one and who does not.
> And, I am not completely finished changing some subsystems - but
> the patches are already big enough for a first wave. I want to get
> some feedback first. Thanks!

I haven't watched your videos yet but I tried one of the patches
  - with make xconfig: OK
  - with make gconfig: OK
  - with make menuconfig: less so, because:
When one switches a menuconfig _on_, one might miss that there are
subsequent options to configure.  (Although the availability of further
options is indicated by the '--->' suffix to the menu title.)
-- 
Stefan Richter
-=====-=-=== -=-- -=-=-
http://arcgraph.de/sr/

Re: [PATCH 0/30] Use menuconfig objects

[David Lang]

On Wed, 11 Apr 2007, Stefan Richter wrote:

> Jan Engelhardt wrote:
>> the following patch series turns some menus into menuconfigs, so they
>> can be disabled whilst "walking" thorugh the parent menu (check the
>> videos [1], [2] to see what I mean), enabling for disabling lots of
>> options _quickly_.
>>
>> I'll send the patches (as a reply to this mail) piece by piece out
>> when I figure out the maintainers to Cc for each.
>>
>> [1] 6.04 MB(1000s) 70 sec http://jengelh.hopto.org/mc/without.ogg
>> [2] 1.96 MB(1000s) 44 sec http://jengelh.hopto.org/mc/with.ogg
>> (Ogg container, Theora Video, no audio)
>>
>> I have not poked on all subsystems (it is quite a lot), but I can
>> already give a glimpse (`ls -1`) of who gets one and who does not.
>> And, I am not completely finished changing some subsystems - but
>> the patches are already big enough for a first wave. I want to get
>> some feedback first. Thanks!
>
> I haven't watched your videos yet but I tried one of the patches
>  - with make xconfig: OK
>  - with make gconfig: OK
>  - with make menuconfig: less so, because:
> When one switches a menuconfig _on_, one might miss that there are
> subsequent options to configure.  (Although the availability of further
> options is indicated by the '--->' suffix to the menu title.)

I use menuconfig almost excludively, there are already quite a few cases where 
the menuconfig is used, so you already need to watch out for the '--->' when you 
turn it on.

I haven't applied this patch series, but I definantly like the concept. I spend 
a _lot_ of time with a new kernel going through and entering menus for the sole 
purpose of disabling everything in them, being able to do so from the level 
above would be nice.

that being said, I also won't object to anything that makes these more obvious, 
but it's not a new problem for people useing menuconfig.

David Lang

[PATCH 0/30] Use menuconfig objects

[Jan Engelhardt]

Hello list,


the following patch series turns some menus into menuconfigs, so they 
can be disabled whilst "walking" thorugh the parent menu (check the 
videos [1], [2] to see what I mean), enabling for disabling lots of 
options _quickly_.

I'll send the patches (as a reply to this mail) piece by piece out
when I figure out the maintainers to Cc for each.

[1] 6.04 MB(1000s) 70 sec http://jengelh.hopto.org/mc/without.ogg
[2] 1.96 MB(1000s) 44 sec http://jengelh.hopto.org/mc/with.ogg
(Ogg container, Theora Video, no audio)

I have not poked on all subsystems (it is quite a lot), but I can 
already give a glimpse (`ls -1`) of who gets one and who does not.
And, I am not completely finished changing some subsystems - but
the patches are already big enough for a first wave. I want to get
some feedback first. Thanks!

`ls -1`:
	menuconfig-acpi.diff
	menuconfig-apm.diff
	menuconfig-ata.diff
	menuconfig-block.diff
	menuconfig-connector.diff
	menuconfig-crypto.diff
	menuconfig-crypto2.diff
	menuconfig-dccp.diff
	menuconfig-fusion.diff
	menuconfig-i2c.diff
	menuconfig-i2o.diff
	menuconfig-ide.diff
	menuconfig-ieee1394.diff
	menuconfig-md.diff
	menuconfig-modules.diff
	menuconfig-mtd.diff
	menuconfig-net-ipvs.diff
	menuconfig-net-sctp.diff
	menuconfig-net-tipc.diff
	menuconfig-netdev-arcnet.diff
	menuconfig-netdev-phy.diff
	menuconfig-netdev-tr.diff
	menuconfig-netdev.diff
	menuconfig-oldcd.diff
	menuconfig-parport.diff
	menuconfig-pcihotplug.diff
	menuconfig-pcmcia.diff
	menuconfig-pnp.diff
	menuconfig-scsi.diff
	menuconfig-w1.diff



Jan
--