Messages in this thread |  | | Subject | Re: CML2 design philosophy heads-up | From | Jes Sorensen <> | Date | 13 May 2001 16:22:59 +0200 |
| |
>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:
Eric> I've said before on these lists that one of the purposes of Eric> CML2's single-apex tree design is to move the configuration Eric> dialog away from low-level platform- specific questions towards Eric> higher-level questions about policy or intentions.
Eric> Or to put another way: away from hardware, towards capabilities.
Eric> As a concrete example, the CML2 rulesfile master for the m68k Eric> port tree now has a section that looks like this:
Eric> # These were separate questions in CML1. They enable on-board Eric> peripheral # controllers in single-board computers. derive Eric> MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from Eric> MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive Eric> MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from Eric> MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive Eric> BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC Eric> from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI
Not all cards have all features, not all users wants to enable all features.
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.
Eric> This is different from the CML1 approach, which generally Eric> involved explicitly specifying each driver with mutual Eric> dependencies described (if at all) in Configure.help.
Yes and it should stay like that. If Richard had wanted all those features enabled per default when an MVME setting was selected, he would have done it in the config.in file, which is perfectly valid to do so today.
Eric> This note is a heads-up. If others with a stake in the Eric> configuration system (port managers, etc.) have objections to Eric> moving further in this direction, I need to hear about it, and Eric> about what you think we should be doing instead. -- <a Eric> href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
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.
Thank you Jes - 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/
|  |