[lkml]   [2001]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Background to the argument about CML2 design philosophy
Date said:
> 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.

You appear to be responding to my email, yet you did not do me the courtesy
of including me in the recipients. Should I assume you're asking this
question of me directly, or was it a rhetorical question? said:
> 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.

Good. You should be prevented from creating a .config which is broken, and
the existing CML1 rules attempt to achieve this. CML2 should continue to do
so, and indeed should do so more effectively and flexibly.

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

I do not fear that CML2 itself will prevent these 'crazy' configurations.
That is why I said that the issue is entirely orthogonal to CML2.

However, it would obviously be possible to introduce new dependencies to the
rules files -- either CML1 or CML2 -- which do prevent such configurations.

What I fear is that such new, unwanted, dependencies may be introduced to
the kernel -- either by accident or by deception -- in the large patch which
introduces CML2 and converts the existing rules files. Subtle changes to
the behaviour could easily go unnoticed in such a large patch.

I am asking that such a deception should not be attempted. The CML2 rules
introduced to 2.5.n should exactly represent the behaviour of the CML1 rules
in 2.5.(n-1). Changes to the policy represented within the rules files can
then be presented afterwards, and should be considered entirely separate to
the change in mechanism. said:
> 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?

I think you are being overly defensive. I was not saying that CML2 is
wrong. I said that I was ambivalent about CML2, and the point I'm talking
about is entirely irrelevant to CML2 - except that I'm trying to make sure
that the large CML2 patch is not used as a vehicle for sneaking other, more
contentious, changes into the kernel.

I want to discuss those changes _separately_ once the CML2 issue is
out of the way, because otherwise people just won't bother to read what I
said, and will assume I'm arguing against CML2 itself.


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.137 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site