Subject: Re: _KERNEL_foo
To: Luke Mewburn <lukem@wasabisystems.com>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-kern
Date: 12/14/2000 13:34:45
Luke Mewburn <lukem@wasabisystems.com> writes:
> On Wed, Dec 13, 2000 at 10:08:50AM -0800, Chris G. Demetriou wrote:
> > lukem@wasabisystems.com (Luke Mewburn) writes:
> > > > Hmm. Personally, I for one would rather see this feature go away
> > > > and we should use existing mechanisms. 
> > 
> > as would I.  it's broken.
> > 
> > There's the issue of _ and .
> > 
> > There's also the issue of expected behaviour of you say:
> > 
> > 	include FOOBAR
> > 
> > in FOOBAR.DEBUG.
> > 
> > All of a sudden, the code paths which used to apply to FOOBAR no
> > longer apply to the kernel you just built -- which from the
> > configuration should be logically the same.
> > 
> > Unless i'm misremembering, _old_ config used to -D the kernel name,
> > and that wasn't done in new config.  Instead, it could be done with
> > options.
> 
> how is it broken?
>
> the definition of _KERNEL_FOOBAR shouldn't break anything, and if the
> basename of the target directory (which is usually the config file
> name) contains wacky characters they get converted to `_')

Think about the example above for a second.

_KERNEL_FOOBAR compiles in code conditional on the 'FOOBAR' kernel.

Say I clone the FOOBAR kernel trivially, e.g. make a new file
FOOBAR_BAZ that includes the FOOBAR config and then add a device or
two, or an additional option or two.

The expectation from that is, rightly, that FOOBAR_BAZ will be the
same as FOOBAR, with the addition of the one or two things specified
in the config file.  That's quite a reasonable thing to expect; it
follows logically from the actions of include (all of the options,
devices, etc.) specified in the included file are included in the
result.


The change you've made breaks that expectation.

I suppose one way to make that better is to start adding definitions
for included files.

However, there's a simpler solution, which preserves the existing
semantics of options and file inclusion, with _no change required_ to
the config sources as they existed before: just add an
appropriately-named option to your config file, and use its name to
conditionalize your code.

If you want to call that option _KERNEL_FOOBAR, well, I think that's a
little bit weird, but at least it'll behave as expected.


That's the right solution, for several reasons, two of which (no
change to code necessary to achieve desired effect, keeps semantics
the same) are mentioned above.  Another is that it encourages better
programming practices.  In particular, it encourages the use of
meaningful names/abstractions, and also encourages sharing of code.



cgd