[lkml]   [2001]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Background to the argument about CML2 design philosophy

David> Actually, the current system has both types. As well as the
David> "hard" dependencies, we also have stuff like
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.


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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.128 / U:0.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site