> Robert P. J. Day wrote:
> > i finally decided to get serious and start looking at the
> > overall config menu structure, to re-arrange the menus and
> > submenus so that it made more sense and flowed more logically,
> > other areas where this would have made sense would be for
> > something like a "Networking" main menu, with submenus for
> > things like ISDN, Wireless and so on, those all being
> > subsets of networking.
> It isn't that simple. ISDN is more than networking, and even
> useable without it. Non-network uses of isdn:
> * Making an answering machine or voicemail from a pc
> and one or more isdn cards.
> * Use isdn for dialing into non-IP services like a BBS.
> So you have a choice between sticking all networking
> things in a network menu (and have stuff like ISDN
> spread out in different places (network and other ISDN at least)
> or put all ISDN in one plave and have network etc. spread over
> various networking technologies like today.
> There is no config layout that is "clean" for everybody,
> because it is fundamentally trying to stuff a generic graph
> into a hierarchical tree.
ok, so i could have picked a better example than ISDN as a
submenu for "Networking", but my main point still stands --
the "Networking support" menu cannot have submenus incorporated
below it without changing the specific Kconfig file for that
directory. and that gets incredibly messy as one tries to
follow a menu structure around the various kernel source
directories. ("Multimedia" was another example of an
unfortunately inflexible menu, so you see my point.)
perhaps you're right -- perhaps there is no nice solution
and there's not much point pursuing this. but given that
linux is being more widely adopted every day, it's clear
that more and more people are going to be building kernels,
it still might be worth trying to address this before it
goes much further.
i'll go with tomas' suggestion to wait until the new
config grammar is out. until then, i'm just going to
play with theoretically reorganizing the menus and see
what eventually makes sense to me, regardless of whether
it's ever implemented or not.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/