Eric> Giacomo Catenazzi <cate@math.ethz.ch>:
>> No. You propmt only one invalid assertion. After you this prompt
>> you continue to validate rules and you will maybe prompt for another
>> invalid rules. But these invalid rules are generally infrequent.
Eric> I may be having problems with your English. I don't think I
Eric> understand this.
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.
>> It is very unlikely to have constraint on string or on integer. But
>> anyway, where is the problem? You simple ask the new value of this
>> symbol.
Eric> The problem is that you're now, in effect, telling me to invent
Eric> a new interactive configurator with different rules than the
Eric> normal one!
Eric> This is a horrible swamp to wander into just to avoid making oldconfig
Eric> users fire up vi occasionally.
No, we're just asking you to make the CML2 parser more tolerant of old
and possibly broken configs.
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?
Going back to the original CONFIG_RTC bug report I filed, all I had to
do was fire up vi and edit the .config file to turn on CONFIG_RTC,
which I think is completely bogus.
CML2 should be able to say "Hey, you need RTC turned on since you've
got SMP on, but it's not. Should I do this for you? Yes/No"
For trully broken .configs, maybe it makes sense to just give up and
say "Hey! This .config is totally bogus, can I just ignore it and
have you redo your config in a sane manner?"
Make the computer do the work, not the user.
John
-
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