David> Actually, the current system has both types. As well as the
David> "hard" dependencies, we also have stuff like
David> CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED,
David> CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED,
David> etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too.
David> These things have already been set up in the way that
David> developers prefer it.
*some* developers prefer it. Not all.
David> CML2 allows us to be more flexible than we were before, and
David> that can be a good thing when used in moderation. But please,
David> for the sake of the sanity of all concerned, do things one at a
David> time. Provide for merging into 2.5 a set of rules which
David> reproduce the existing CML1 behaviour in this respect.
Can you define what you mean here? It's not really clear to me, and I
suspect others.
David> Eric, if you want to make further changes later to introduce
David> new 'modes' for kernel configuration, that's an entirely
David> separate issue. Please don't confuse the issue by trying to do
David> it at the same time as introducing CML2.
I don't think he is introducing new modes, he's just trying to make
sure that you can't create a .config which is broken. Part of my
complaint early on was that it would just barf on a config it thought
wasn't legall, and just drop me to the 'vi' level. I don't think this
is acceptable because you (CML2 or CMLxxxx) should be able to prompt
the user for a suggested fix.
David> CONFIG_AUNT_TILLIE does not require CML2.
Correct.
David> CML2 does not require CONFIG_AUNT_TILLIE.
Correct. And never has offered it either!
David> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the
David> existing behaviour of config options to make that the default,
David> until we've settled the discussion about CML2.
I think it comes down to people who just want one or more of:
- the existing interface of vi .config; make oldconfig
- fear that CML2 won't let them make crazy configurations, such as an
8-way SMP box with ISA. Can't see how CML2 would restrict this
choice myself.
- Don't want to install python 2.x for a kernel upgrade.
- fear that some configuration corner case will be handled wrong for a
strange (read not common) system config.
All that CML2 does is enforce dependencies in the configuration
language. You can't make a .config which conflicts. Admittedly
there's nothing stopping you from hacking it with vi after the fact,
but why?
If you run into a case where you have a config which would work, but
CML2 doesn't let you, why don't you fix the grammar instead of saying
CML2 is wrong? Let's not confuse these two issues as well.
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/