Re: CML2 design philosophy heads-up

Eric S. Raymond
2001-05-13T15:26:42Z

Jes Sorensen <jes@sunsite.dk>:
> Not all cards have all features, not all users wants to enable all
> features.

Yes, I understand that. You're not reading the derivations correctly.
Let's take an example:

derive MVME147_SCSI from MVME147 & SCSI

This doesn't turn on MVME147_SCSI on every MVME147 board. It turns
on MVME147_SCSI when both MVME147 *and SCCI* are on. So to suppress
MVME147_SCSI, one just leaves SCCI off.

All these derived symbols will still be controllable. The difference
is that instead of being controlled by a low-level hardware-oriented
question they're controlled by a capability or subsystem symbol like
SCSI, NET_ETHERNET, or SERIAL.

> Eric> # These were separate questions in CML1 derive MAC_SCC from MAC
> Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from
> Eric> (SUN3 | SUN3X) & SCSI
>
> As Alan already pointed out thats assumption is invalid.

I'm in touch with Ray Knight directly and will fix this as he requests.

> Yes I have objections. I thought I had made this clear a long time
> ago: Go play with another port and leave the m68k port alone.

Does this mean you'll take over maintaining the CML2 rules files
for the m68k port, so I don't have to? That would be wonderful.

Reasoned objections can change my behavior. Grunting territorial
challenges at me will not. You have two options: (1) persuade Linus
that the whole CML2 thing is a bad idea and should be dropped, or (2)
work with me to correct any errors I have made and improve the system.
Growling at me and hoping I go away won't work, not when I've invested
a year's effort in this project.
--
Eric S. Raymond

As with the Christian religion, the worst advertisement for Socialism
is its adherents.
-- George Orwell