Re: Background to the argument about CML2 design philosophy

John Stoffel (stoffel@casc.com)
Mon, 21 May 2001 16:38:34 -0400


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 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/