John Stoffel <stoffel@casc.com>:
> He's saying that when you find the first invalid assertion, such as
> not having CONFIG_RTC defined, when reading the .config file, you
> should prompt for a fix. Then once the input is taken, continue your
> checks, prompting for each following problem as needed.
The problem lies in that innocent-sounding phrase "prompt for a fix".
Generating such a prompt is a far deeper problem than you seem to realize.
> No, we're just asking you to make the CML2 parser more tolerant of old
> and possibly broken configs.
The parser is not the problem. The parser tolerates old, broken
configs quite happily. Gives you a nice pop-up message when it hits
an invalid symbol. No, the problem is that y*ou're asking me to make
the deduction machinery solve a problem that is (a) ill-defined and
(b) subject to a 3^n combinatorial explosion.
> I haven't looked at the parser in any detail, but I assume that there
> are heirarchal configuration settings. When there is a mis-match,
> where a sub-option conflicts with an upper option, how hard would it
> be to print a warning, and just reset the sub-option to an acceptable
> state?
Clever idea -- not so clever that stupid me didn't think of it six months
ago, but clever. Might even work if the constraints always obeyed a neat
hierarchy. They don't. The constraints can reach across the tree.
In many cases there is no way to define "upper" or "lower". (X86 and
SMP) implies RTC!=n is actually a good example. Here's where they fit
in the tree:
main 'Linux Kernel Configuration System'
arch 'Processor type'
X86 'Intel or compatible 80x86 processor'
generic 'Architecture-independent feature selections'
SMP 'Symmetric Multi-Processing support'
archihacks 'Architecture-specific hardware hacks'
RTC 'Enhanced Real Time Clock Support'
Yes, that's right -- they're all at the same level. OK, X86 is frozen
by hypothesis. So now give me a rule for telling which of SMP and RTC
is "superior". Note that in order to make the rule usable by the
deducer, it can't know anything about the semantics of the symbols.
Do you sense an abyss yawning beneath you yet? If not, hold on.
You'll see it shortly.
I started to write up a full explanation but I think I'm going to post
that separately. It's long.
-- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - 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/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:15 EST