Re: Configuration language issues (was Re: drivers/net/Config.in cleanup)

From: Werner Almesberger (almesber@lrc.epfl.ch)
Date: Tue Mar 07 2000 - 19:22:23 EST


Michael Elizabeth Chastain wrote:
> On the level of theory, this is a bad construct because nothing requires
> the user to traverse the "Peripheral Buses" menu in order to enter the
> "Network Drivers" menu.

Ah, you want to restructure the presentation ... should be interesting
to see what this yields. I'm a little afraid that the large number of
options may over-compensate the clarity you gain by exposing the
dependency structure.

> And in practice, users report a lot of "I want to turn on Feature Y but
> I can't figure out which Feature X enables it".

I'd suggest that this is a different problem, though. In many cases,
there are highly non-obvious dependencies, e.g. CONFIG_NET_SCH_INGRESS
depends on CONFIG_NETFILTER (net/sched/Config.in), which actually even
happens to be defined in a parent menu.

IMHO, a configuration editor should have a function that simply shows
the things an item depends on (*). As a luxury gadget, it could also
show the options that depend on this item ...

(* presentation could be an issue. It would certainly help just to
   list the names (or descriptions, in cases where the editor doesn't
   display the configuration names themselves). In a further step, it
   may show the equation (e.g. "EXPERIMENTAL && !IO_APIC"), give
   qualitative indications (e.g. "EXPERIMENTAL has a positive
   influence, IO_APIC a negative" - well, maybe this is too vague to
   be useful ;-), or give examples what you have to do to change the
   option in a specific way (e.g. "To enable, do any of these:
   (1) Enable EXPERIMENTAL. (2) Disable IO_APIC."). Then there is the
   issue of higher-order dependencies, but I think this can be left
   to the user to resolve. Most of them should be trivial anyway.)

For all this to work, some configuration editors (e.g. Configure and
menuconfig) would also need an option to show currently unavailable
options. xconfig shows them all the time, which I consider a mixed
blessing ...

> Sequential evaluation has more constraints than my weaker "tree based"
> scoping constraints

You mean the other way around ? Sequential evaluation still allows
definition in siblings.

> That would help out with internationalization too.

We may end up with a cabal ;-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH       werner.almesberger@ica.epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:24 EST