Messages in this thread |  | | Date | Sun, 20 May 2001 13:14:57 -0400 | From | "Eric S. Raymond" <> | Subject | Background to the argument about CML2 design philosophy |
| |
Those of you who have become confused about the current argument over CML2 should read this...
David Woodhouse <dwmw2@infradead.org>: > After the discussion of MAC and SCSI config options many moons ago in this > thread, I was left with the impression that the constraints which were > being objected to were not dependent upon a NOVICE mode, but were > unconditional. > > Was this merely a mistake in the conversion of the ruleset? Do you have a > policy that the default behaviour should be similar to that of CML1, or at > least that such behaviour should be available through one of the > modes? If not, please consider doing so.
They were unconditional. It looks like a recap of history is in order.
Until very recently, like ten days ago, I had a policy of altering the CML1 behavior as little as possible while I got CML2 up and running. Some change had been inevitable because of the move to a single-apex menu tree, but I tried to hold that to a minimum.
But I have reached a point where the configurator codebase is stable and works as a drop-in install on top of a stock kernel tree. I'm not even getting requests for UI tweaks any more. So the CML2 engine is essentially done (modulo the occasional minor bugfix).
This made it time to start thinking about tuning the rulesfile to make configuration easier. At the same time, I was dealing with another problem; missing entries in Configure.help. When I got handed the maintainer's baton, there were 547 of these. I have written outright over 300 new ones; Steven Cole and I have collected another 50 or so.
To reduce the problem further, I looked for symbols with missing entries that I could turn into derivations, eliminating their questions and the requirement for a help entry. (A CML2 derivation is like a CML1 define; it's a formula that sets a symbol from the value of other symbols without user input.)
The first candidates I found were questions associated with built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and Sun3x, and with built-in facilities on the MVME147 single-board computer. So I wrote derivations that looked like this:
# These were separate questions in CML1. They enable on-board peripheral # controllers in single-board computers. derive MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI
# These were separate questions in CML1 derive MAC_SCC from MAC & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI
By doing this I killed two birds with one stone -- got rid of some holes in Configure.help and (more importantly) moved the configuration experience away from low-level, hardware-oriented questions towards where I think it ought to be. That is, you specify a platform and the services you want and the ruleset computes the low-level facilities to be linked in.
This represented a change in the design philosophy of the ruleset, not something I wanted to do without input from the developers and port managers. So I broadcast "CML2 design philosophy heads up".
After some back-and-forthing about the technical facts, several things emerged:
1. The Mac derivations were half-right. The MAC_SCC one is good but Macs can have either of two different SCSI controllers. I fixed that with help from Ray Knight, who maintains the 68K Mac port.
2. Nobody had a problem with the SUN3_SCSI derivation.
3. The MVME derivations are correct *if* (and only if) you agree to ignore the possibility that somebody could want to ignore the onboard hardware, plug outboard disk or Ethernet cards into the VME-bus connector, and do something like running SCSI-over-ATAPI to the outboard device. (I missed these possibilities when I wrote the derivations.)
I used case 3 to explore a touchy question about design philosophy, which is really what caused all hell to break loose. The question is this: holding down configuration complexity is a good thing, but supporting all hardware configurations that are conceivably possible is also a good thing. How should we trade these good things off against one another?
The MVME situation is an almost perfect test case, because while breaking the assumption behind that derivation is physically possible it would be a rather perverse thing to do. The VME147 is an old design, dating from 1988; it's long since been superseded by MPCxxx SBCs based on the PowerPC that have a better processor, lower power consumption, and more on-board peripheral hardware. IDE/ATAPI didn't exist during most of its design lifetime, and the only way anyone is ever going to hook an outboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for some garage project.
So the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is "yes, sometimes" is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. But the cost of deciding that the answer is "no" will be some pretty serious complexity headaches both in the configuration user experience and (down the road) in the maintainability of the ruleset.
So far, I have to say I'm disappointed in the quality of the debate. Almoist nobody seems to want to think about this tradeoff globally, as a systems design issue. Instead, I'm hearing a lot of reflexive chuntering that we have to do things a certain way because we've always done them a certain way, and who am I to even dare *think* about raising different possibilities? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
[The disarming of citizens] has a double effect, it palsies the hand and brutalizes the mind: a habitual disuse of physical forces totally destroys the moral [force]; and men lose at once the power of protecting themselves, and of discerning the cause of their oppression. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 - 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/
|  |