Messages in this thread |  | | Date | Thu, 3 May 2001 10:45:11 +0200 | From | Ingo Oeser <> | Subject | Re: Why recovering from broken configs is too hard |
| |
On Thu, May 03, 2001 at 03:47:55AM -0400, Eric S. Raymond wrote: > OK, so you want CML2's "make oldconfig" to do something more graceful than > simply say "Foo! You violated this constraint! Go fix it!"
Yes, that would be nice.
> The obvious thing to try is to start with the configuration you have > and try mutating the variables that occur in the broken constraint(s).
No, that is not the obvious way for me.
> Have I got the point across yet? There are *no* good solutions > to this problem. There aren't even any clean ways to separate > easy cases from hard ones.
There might be.
If the current dependencies of the symbols can be represented as a tree (or can be topologically sorted, to be CS-correct), then I would only care about the "leaves" of that tree.
Most added symbols in newer configs are added as leaves. So this should suffice in most situations.
We also have defaults for all new values in our arch/$ARCH/defconfig.
So we read all symbols from .config and from defconfig into 2 flat tables (no constraints applied here!) together with their values.
If we miss a symbol from .config, we ask the user, using the one from defconfig as default, if we cannot derive its value from our constraints.
If we have a symbol in .config, that we don't know about, we simply ignore it (and tell the user that it's "obsolete or renamed").
If the value for a symbol is there, but doesn't fit our constraints: Ask the user or use the opposite (if it is boolean).
That was the 99% case: "leaves". They are easy.
Now the nodes. We can try fixing the config by changing the symbols from leaves, to root (to save derives).
But we only give this solution a certain amount of "tries" and give up (or tell the user, that we have a hard time here and aks for continue or abort and fixing by hand), if we either tried to often or a certain amount of time has passed (30secs maximum until next prompt).
This is no "perfect" solution, but it covers the common cases well enough.
Eric, what do you think about that "dirty hack" variant? ;-)
And will the derivation be in nearly constant time, if I change one symbol?
Regards
Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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/
|  |