I need some free time to actually run CML2; I haven't used it since
0.7 or so. So if I'm out in left field, someone just bang me with a
clue stick.
Alan Cox writes:
> I'm quite happy for oldconfig to continue to do what it did before. I'm
> quite happy to accept its mathematically imperfect, because it hasnt
> gone far wrong yet
I'm in Alan's camp here. The invariant I care about is: that the config
tool always *outputs* a legal configuration. I'm sure that ESR is
committed to that invariant.
There are lots of different cases that can cause the *input* to be
illegal. The three existing flavors of configuration have slightly
different ways of handling these cases; basically, they have all been
good enough for field deployment.
If some option drops out and the developer needs it, they will fire up
menuconfig/xconfig and stick it right back in. If some option gets
turned on by accident they often won't even notice. And if there's a
big tangle of sensitive options, then they will care enough to check
the options that they care about in menuconfig/xconfig.
And sometimes there will be a case where an option acquires a new
dependency and maybe the tool goes down a bogus path. Such as:
the user has X86=y SMP=y RTC=n, and then a new patch makes RTC depend
on SMP, and then a config tool decides that to fix the problem by
setting SMP=n. Shock!
The first hacker to figure it out will post to linux-kernel in about
an hour. There will be a small wave of people saying "I'm trying the
bleeding edge 2.5.XX kernel and my SMP seems strange", met by another
small wave of people saying "that's because ...".
It would be nice for CML2 to point out any changes that it makes.
But users can do that themselves by diffing the file before and after.
People who share multiple configs between multiple revisions of
the kernel usually know how to use diff.
More generally, CML2 does not have to be perfect. It just has to be
a lot better than CML1 in most places, and no worse than CML1 in any
significant area.
Michael
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
