Eric> Giacomo Catenazzi <[EMAIL PROTECTED]>:

>> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to