Giacomo A. Catenazzi <cate@dplanet.ch>:
> I think that a fundamental requirment is that 'make oldconfig' should
> validate any configurations (also the wrong conf).
> (If you correct your rules, our old .config can be invalid on a new
> kernel, and we don't want regualary edit our .config).
Validating is exactly what it's doing now. What you really want is for it to
semi-automatically *correct* broken configurations, which is very
different and much harder.
> My proposal is instaed of complain about configuration violatation,
> you just wrote the possible correct configuration and prompt user to
> select the correct configuration.
> In the case you cite, e.g. oldconfig shoud prompt:
> 1) SMP=n
> 2) RTC=m
> 3) RTC=y
> (assuming the ARCH is invariant).
You, and the other person who proposed this previously, are getting
way too hung up on this particular easy case and not thinking about
the general problem.
The number of prompts goes up with the number of variables in the constraint.
But the number of possible correct configurations goes up as 2**n -- actually,
3**n because we have trits.
What you're saying, in effect, is that if f is number of frozen variables
in the constraint then the configurator ought to generate 3 ** (n - f)
possible correct models and prompt for one of them. Since f typically
equals just 1 that number goes up really fast with n.
And what if one of the variables in the constraint is of integer or
string type? In that case the number of possible models to be
prompted for is effectively infinite. (Finite but very very large).
You are proposing an interface that will handle easy cases but blow
up in the user's face in any hard one. That's poor design, frustrating
the user exactly when he/she most needs help.
-- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>"The bearing of arms is the essential medium through which the individual asserts both his social power and his participation in politics as a responsible moral being..." -- J.G.A. Pocock, describing the beliefs of the founders of the U.S. - 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:10 EST