Messages in this thread |  | | From | David Woodhouse <> | Subject | Re: Background to the argument about CML2 design philosophy | Date | Tue, 22 May 2001 14:45:53 +0100 |
| |
stoffel@casc.com 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?
stoffel@casc.com 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.
stoffel@casc.com 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
- 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/
|  |