Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

[e-mail] 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?

[e-mail] 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.

[e-mail] 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.

--
dwmw2