Linus Torvalds <[EMAIL PROTECTED]>: > My pet peeve is "centralized knowledge". I absolutely detested the first > versions of cml2 for having a single config file, and quite frankly I > don't think Eric has even _yet_ separated things out enough - why does the > main "rules.cml" file have architecture-specific info, for example?
I'm not certain what you're objecting to, and I want to understand it. There are rules that use architecture symbols to suppress things like bus types. I presume that's not a problem for you, but tell me if it is. My best guess is that you're objecting to the archihacks and kernelhacking menus, or the architecture-dependent derivations down around line 330. In general what's going on here is actually the beginnings of an attempt to replace architecture-dependent questions with architecture-*independent* questions. It looks kind of ugly right now because it's too early in the game to mess with the config-symbol namespace -- but, for example, I want to merge the MATH_EMULATION and MATHEMU symbols eventually. And there ought to be a generic set of toggles for kernel-debugging that present to the user as cross-platform capabilities rather than platform- specific switches. In those two menus I've gathered together architecture-specific symbols that I think ought to merge into cross-platform capabilities. But I know there is other cruft in there for historical reasons. Since you've brought up the point, I'll do a cleanup pass on these and see how much I can exile to the arch/*/rules.cml files. There isn't really any help for the ceoss-platform derivations. There are exactly four of these. I've worked hard at holding them to a minimum: derive HAVE_DEC_LOCK from (SMP and (ALPHA or X86_CMPXCHG)) or SPARC or PPC derive HIGHMEM from HIGHMEM4G or HIGHMEM64G or SPARC derive MAC_HID from (ALL_PPC and INPUT!=n) or (MAC and INPUT_ADBHID) derive PC_KEYB from ARM_PC_KEYB or MIPS_PC_KEYB If you notice that each right-hand part includes port symbols from at least two different architectures, I think it will be clearer why these are necessary. CML1's way of doing this had the problem that it was hard to know by inspection of the rulebase under what circumstances a given symbol was actually turned on. This is why CML2 has a rule that each symbol is derived (or occurs in a menu) exactly once. With some work I could relax this restriction, but I don't want to -- it's a major factor in keeping the rulebase's complexity down in the range that a human brain can mentally model. > That's a big step backwards as far as I'm concerned - we didn't use to > have those stupid global files, and each architecture could do it's own > config rules. Eric never got the point that to me, modularity is _the_ > most important thing for maintenance. Oh, no, I got that all right. What I have been trying to do is trade off correctly between modularity (which helps maintenance) and the advantages to the configurator *users* of having a global capability namespace, single-apex menu structure, and the symbols-to-prompts mapping in one file. These choices weren't made at random. You don't readily see their advantages because you have a nose-to-the-code, maintainer perspective (quite properly so, in most cases). But in designing the configuration system, simplifying life for *users* is just as important, if not more so. Sometimes this implies not going as far in the direction you favor direction as you might like (monolithic Configure.help is an example). > Something I also asked for the config system at least a year ago was to > have Configure.help split up. Never happened. It's still one large ugly > file. Driver or architecture maintainers still can't just change _their_ > small fragment, they have to touch a global file that they don't "own". Yes, there are two reasons for this. The contingent, historical reason is that I wanted to get Configure.help in good shape before thinking about dispersing it. That work is now done (though you haven't kept up to date with it). The design reason is that having a single file with all the symbol-to-prompt mappings in it is really helpful when you want to localize the rulebase for another language. I'm still leaning towards keeping symbols.cml together just to make it easier for people to do and distribute translations of it. I think this is an issue that is rising in importance. I have no problem with assuming that kernel hackers are English-literate, but it's no longer an assumption we should make about people *building* kernels. I want to encourage CML2 and question-string localizations for French. And German. And Thai. And Ethiopian. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> If I were to select a jack-booted group of fascists who are perhaps as large a danger to American society as I could pick today, I would pick BATF [the Bureau of Alcohol, Tobacco, and Firearms]. -- U.S. Representative John Dingell, 1980 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel