Hi,
On Mon, 28 Nov 2005, Rob Landley wrote:
> I understand that bit, but the problem with the single pass you suggested is
> that symbols can be set by dependencies (like the one afflicting CONFIG_PM),
> and those are neither off nor at their default, yet they're not actually
> required.
Setting everything to n can still be done in single pass, but that
requires working around the normal API and setting the values directly,
e.g.:
for_all_symbols(i, sym) {
if (!(sym->flags & SYMBOL_NEW))
continue;
switch (sym->type) {
case S_BOOLEAN:
case S_TRISTATE:
sym->user.tri = no;
sym->flags &= ~SYMBOL_NEW;
}
}
Now you only need to flush the old precomputed values
(sym_clear_all_valid()) and you're done.
> This starts sounding like a directed graph, and I am _not_ familiar enough
> with the kconfig structure to try to work it out yet.
The kconfig data is a directed acyclic graph, which allows to do most
operation deterministically in a single pass.
The problem is to transform the data from a valid state to another valid
state. The normal API allows only changes which keep the data in a valid
state (e.g. you can't set a not visible symbol), but it's possible to
bypass this and set multiple symbols, flush the old state and a new state
will generated which is consistent with the Kconfig rules.
Currently only conf_read() does this, i.e. you can throw pretty much any
.config at it and it will generate a valid (but not necessarily useful)
config from it.
> > Symbols can be hidden by new dependencies.
>
> Something gets enabled that then disables other things? Hmmm...
>
> I've been thinking of things in terms of visibility. The menu this symbol
> lives in either is or isn't open, and I can't set the symbol unless its menu
> is open. If two different symbols control visibility for the same menu, it's
> still really that the menu has one guard symbol and that dependencies of
> other things are messing with that guard symbol. I think.
>
> The way I've been thinking about miniconfigs is that each symbol in a
> miniconfig is an action changing the default state. When you read in a
> miniconfig, you start with all symbols at default allnoconfig values, and
> then make this list of changes to that state (in order) letting the
> dependencies do their thing with each change. (This maps to what a user
> would do in menuconfig, selecting X, Y, and Z in this order. I could write
> it down on a piece of paper for the user, so why can't the machine do it for
> me?)
This is not how it works (see above), reading the .config and user
interface changes are two different things.
After the config has been read, the data is brought into a consistent
state, which may mean the actual symbol value may be different, as they
are limited by their dependencies.
> > Yes, some symbols are hidden behind a lot of dependencies, if a user wants
> > to enable a new option, he only adds one new option and kconfig can try to
> > figure out the missing options.
>
> You mean enabling a symbol in a closed menu would open the menu (but leave
> everything else in it disabled, rather than at default values)? So
> miniconfig wouldn't have to specify guard symbols at all anymore?
>
> That would be nice. I suspect there are guard symbols that are also
> functional (CONFIG_SCSI comes to mind), so the rule would have to be
> something like guard symbols are only discardable when something in the menu
> they protect _is_ specified.
There are no special guard symbols, so if a SCSI driver is requested, this
means CONFIG_SCSI needs to be set.
bye, Roman
-
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]
