On Thu, Nov 29, 2001 at 02:48:50PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> > > Tom Rini <[EMAIL PROTECTED]>:
> > > > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > > > arch/$(ARCH)/boot/rules.cml ?
> > >
> > > Nothing. But if they aren't single declarations, what's going to
> > > *keep* them there?
> >
> > What? If the arch maintainer decides to move them, that's their
> > problem. I can't really think of a good reason. If you really want to
> > enforce a single common spot for 'em, make it a policy thing or at least
> > strongly recommended.
> >
> > But I also don't see what the problem is anyhow. What are you worried
> > might happen?
>
> Suppose we have split declarations for derivations or defaults of
> symbols that are shared across architectures. It would then be
> locally convenient for configuration maintainers to move these
> declarations from the top-level rules.cml file piecemeal to rules
> files in different arch subtrees, or elsewhere.
So say do it in arch/$(ARCH)/.../rules.cml, yes?
> The problem is that it then becomes globally difficult for someone
> reading the rulebase to know what the derivation or default behavior
> of a symbol actually is.
But there is no global 'default'.
> Different pieces of the behavior could be
> scattered all through the rulebase. Even with cross-referencing tools
> (which I have written and tested and use regularly for
> sanity-checking) the effort involved in assembling and integrating
> that picture could be significant. (It already is for the one case
> where supporting split declarations was unavoidable, which is
> visibility predicates.)
True, but these common symbols have architecture-specific meanings
anyhow. As a general rule what your saying makes sense. Like for
CONFIG_SERIAL_CONSOLE, all of the gunk surrounding that should be in one
place. But in this case what 'CONFIG_ZIMAGE' means even varries on
different arches. Aside from it being gzip'ed kernel + bits you can't
really assume anything.
> John Cowan thinks I'm unduly influenced by having had to maintain the
> rulebase all by myself up to now. He's half-right; I've got battle
> scars, yes indeed I do. The last thing I want to do is casually
> create a maintainability problem for anybody who will need to take a
> global view of the config rules in the future. Like...say...Linus?
I certainly hope Linus won't have to know nearly as much about all of
the rule files as you do, or ever really want to for that matter. I
still argue that if all of the derivations of
CONFIG_{ZIMAGE,BZIMAGE,VMLINUX,VMLINUZ,et al} are in
arch/$(ARCH)/boot/rules.cml, as a policy and logic thing, it wouldn't
matter. I can't see anyone wanting to have additional rule-files in
subdirectories (I plan on asking about 'em in 1 rule file :)).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
