Jes Sorensen <[EMAIL PROTECTED]>:
> 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.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
As with the Christian religion, the worst advertisement for Socialism
is its adherents.
-- George Orwell
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
