Re: Linux 2.6.22-rc1

["Satyam Sharma" <satyam.sharma@gmail.com>]

Hello,

On 5/15/07, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> [...]
> They are just a menu

Ok, so they don't really affect Makefiles / sources (and thus builds).
In that case I'd suggest that let's please change the names of such
menuconfig options from CONFIG_ to CONFIG_MENU_, otherwise
we really screw the text-based "make oldconfig" folks who think
that they're taking a build-related (and not presentation-related)
decision when confronted with a:

Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)

kind of option. OTOH:

Ethernet (1000 Mbit) (MENU_NETDEV_1000) [Y/n] (NEW)

taxes a make-oldconfig-using-person's intuition a little less, IMHO.
So this'll hopefully take care of Tilman's and Stefan's gripes:

On 5/15/07, Tilman Schmidt <tilman@imap.cc> wrote:
> (Except for the "this
> menu" part which might appear rather cryptic to users of the
> curses based interface who don't see any menu.)
> [...]
> Point is, without grepping through the Kconfig the user has no
> way of knowing that the question comes from a menuconfig in the
> first place ...
> ... s/he cannot be sure the option doesn't directly affect
> code generation.

and

On 5/15/07, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> One problem is, nobody can see easily whether saying Y is merely the
> ticket to get into the menu, or whether it on its own will cause
> something to be built.

?

On 5/15/07, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> that can be switched on or off.
> It is for those people that start with an arbitrary .config and
> work their way through menuconfig to disable all the parts they
> do not want. So, point no. 1:
>
>   * Disabling this menu disables all the fluff inside it,
>     without needing to enter the menu and disable each
>     option one by one (as was the case previously)

This kind of promise was really nice, and why I liked Jan's
menuconfig patches a lot.

But if:

On 5/15/07, Tilman Schmidt <tilman@imap.cc> wrote:
> Another essential piece of information. I seem to remember other
> menus which, when disabled, kept the selection status of the
> options inside and just hid them from view.

is true, then are we really gaining much from these configmenu's?

[unrelated]
I wish these new constructs were called "configmenu" and
_not_ "menuconfig". It causes confusion with the "menuconfig"
master Makefile rule which has nothing to do with these new
"configmenu"s.
[/unrelated]

> Then of course, one can also turn these menuconfig on (apparently!)
> to be able to descend into them and select some drivers they like.
> Point no. 2:
>
>   * Since Jens Axboe's stance ["default y idiocy"] is to have
>     these menus disabled by default, people should most likely
>     enable them first before they will be able to enter them.

I do agree that anything non-essential (even if it's just a presentation
menu that doesn't affect builds) must be default n.

>     (I would have wanted them to be always 'y' - it does not affect
>     the build, just opens all menus by default)

IMHO, the real problem with "default y" menuconfig's, is that they
cause unpleasant surprises to those folks that use the text-based
"make oldconfig". They get confronted with choices that they never
bothered about (or even knew existed) previously, and have no
idea how to answer them -- same problem faced by Tilman, when
he used oldconfig.

> >Seriously, it might be a tad more efficient if the help texts were
> >written by those who invented the options in the first place.
>
> menuconfig NETDEV_10000
>         bool "Ethernet (10GbE)"
>         ---help--
>         Say Y here to actually be able to go into this menu
>         and select some drivers that we think belong to the
>         "10 Gigabit Ethernet" family.
>
>         If unsure, it is unwise to say N!
>
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.

IMHO, those using "oldconfig" are often looking towards doing
things quickly ... doesn't help them if they have default y menu's
that they need to "?" upon then to see what they're really about.

> >For a start, it shouldn't require users to grep through Kconfigs
> >and Makefiles in order to find out what effects an option has.
>
> menuconfigs are some special kind in that they combine an option
> with a menu. Perhaps now that some ->menuconfig patches have gone
> in, more people will get to know these constructs.

I think what happened here is that Jan really only considered the
"make menuconfig" users with these new constructs (which makes life
really simple for them), but "oldconfig" users were unfortunately in for
unpleasant surprises ...

On 5/15/07, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> PS:  I still believe that Kconfigs shouldn't by overly burdened with
> presentation.  Presentation should mostly be left to the UIs.  And the
> UIs shouldn't be created by kernel hackers...  ;-)

Kernel dev's can still try, can't they ;-) I do agree that Kconfig is
primarily a build dependency language, but also, note that linking
Kconfig dependency rules with presentation isn't an idea that seems
to be fundamentally broken or anything.

Just my 2 paise,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/