Messages in this thread |  | | Date | Sat, 5 May 2001 19:27:31 -0400 | From | "Eric S. Raymond" <> | Subject | CML2 design philosophy heads-up |
| |
I've said before on these lists that one of the purposes of CML2's single-apex tree design is to move the configuration dialog away from low-level platform- specific questions towards higher-level questions about policy or intentions.
Or to put another way: away from hardware, towards capabilities.
As a concrete example, the CML2 rulesfile master for the m68k port tree now has a section that looks 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
If it isn't obvious, the intent is that if you specify (say) both MVME147 (a machine type) and SERIAL (a capability) you automatically get the specific driver support under MVME147_SCC.
This is different from the CML1 approach, which generally involved explicitly specifying each driver with mutual dependencies described (if at all) in Configure.help.
I've created a number of derivations of this kind recently. I'm not going out of my way to do this, but what I am trying to do is reduce the number of symbols undocumented in Configure.help to zero (I've got it down to 243 from 547 when I started). When I can eliminate the need for a configuration question and associated help by writing this kind of formula, I'm doing so.
This note is a heads-up. If others with a stake in the configuration system (port managers, etc.) have objections to moving further in this direction, I need to hear about it, and about what you think we should be doing instead. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - 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/
|  |