Re: [PATCH] make miniconfig (take 2)

[Roman Zippel <zippel@linux-m68k.org>]

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 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/