Hello,
On 5/15/07, Jan Engelhardt <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
