Messages in this thread | | | Date | Wed, 11 Apr 2001 21:28:04 -0400 | From | esr@thyrsus ... | Subject | Re: CML2 1.0.0 release announcement |
| |
Jeff Garzik <jgarzik@mandrakesoft.com>: > esr@thyrsus.com wrote: > > But, as a separate issue, the CML2 design *could* be reworked to support > > a multiple-apex tree, if there were any advantage to doing so. I don't > > see one. Do you? > > Yes, because the current system is directed not by a central file, but > by an architecture-specific config.in. Compartmentalized Config.in > files are easy to include and even easier to exclude selectively. It's > pretty pointless for S/390 arch to parse a ton of driver config entries > it will never present to the user; that wastes memory and slows down the > configuration system.
The low-level answer is that the configurator doesn't pay the parse-time cost; the CML2 compiler does all that and presents the configurator with a rulebase object that is not large enough for the incremental I/O or memory cost of the "useless" information to be significant. (I'm not handwaving here, I've actually profiled this; the rulebase object for 2.4.3 is only 342K on disk and less than that in core.)
BTW, CML2 only has a "central file" in a rather trivial sense. Here's what the code to include the port-specific rules looks like:
source "arch/i386/rules.cml" source "arch/alpha/rules.cml" source "arch/sparc/rules.cml" source "arch/mips/rules.cml" source "arch/ppc/rules.cml" source "arch/m68k/rules.cml" source "arch/arm/rules.cml" source "arch/sh/rules.cml" source "arch/ia64/rules.cml" source "arch/parisc/rules.cml" source "arch/s390/rules.cml" source "arch/cris/rules.cml"
The real issue isn't that they're "centralized", it's that they're siblings under a top-level architecture menu (which most users won't see because normal invocations of the configurator supply that answer from the command line, just as in CML1). Which brings me neatly to my next point...
The higher-level answer is that you're confusing an implementation issue with a design issue. Beware of such premature optimization, for as the hierophant Knuth hath revealed unto us, it is the root of all evil. To persuade me to go back to a multiple-apex tree you'd have to show that there is a *design* or complexity-control advantage to compartmentalizing the configuration information in that way. Maybe there is one, but nobody's shown it to me yet.
(In truth I don't dismiss implementation concerns quite as cavalierly as it might sound from the above. But buying a linear speedup wouldn't be good enough to make me change the design. A quadratic speedup might be, but none of CML2's algorithms are quadratic in the number of symbols in the rulebase.) -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! - 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/
| |