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/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:17 EST