esr@thyrsus.com said:
> David Woodhouse <dwmw2@infradead.org>:
> > However - the thing to which I and many others object most strongly is the
> > rulebase policy changes which appear to be inseparable from the change in
> > mechanism. That is; we've tried to get you to separate them, and failed.
> Failed? Hardly.
> The only rulebase policy change Tom Rini was able to identify in a
> recent review was the magic behavior of EXPERT with respect to entries
> without help. Which I then removed by commenting out a single
> declaration.
> There is a widespread myth that the CML2 rulebase is lousy with
> "policy changes". I don't know how it got started, but it needs to
> die now.
Each time I've even glanced at it, I've seen bogus changes. I haven't
looked at it recently, so cannot refute your statement that they are now
all gone. You'll forgive me if I take your assertion with a pinch of salt,
though?
A good way to kill this myth, if myth it is, would be to set up a test
suite, as I suggested before. You already have a 'randomconfig' for CML2, I
believe? I think there's also one for CML1.
Repeatedly make a random config (for a random architecture), with either
CML1 or CML2. Make oldconfig with the other CML, then with the first again.
If there are any differences between the original randomconfig output and
the output after the two 'oldconfig' stages, you've hit something that may
be a problem.
Every time you hit such a difference, either fix it or document it and
justify it. Ensure that the list of such justifications required is small,
in order to improve the chance of CML2 being accepted.
You are permitted to fix these differences by modifications to the CML1
rules. The only cases where you should accept differences are where the
CML1 behaviour does not accurately represent the intention of the
developer, the developer has agreed with you, _and_ CML2 cannot implement
the same buggy behaviour.
Note the third condition there. If CML2 _can_ implement the buggy CML1
behaviour, do so -- you can fix the rules _later_.
-- 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/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:11 EST