Re: config(5) break down

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Mar 08, 2010 at 05:08:56PM +0900, Masao Uebayashi wrote:
 > > That line of reasoning only makes sense if splitting things into
 > > multiple files provides some kind of scoping, or encapsulation, or
 > > other form of abstraction.
 > 
 > One *.conf matches one module.

Again: why? You've latched onto this as (apparently) a key point of
what you're doing, except that I don't see why it's necessary or even
desirable or how it relates to any of the other things you've
suggested.

 > We'll always build modules as single object
 > like intermediate *.a in userland.  Expose only necessary symbols.  Multiple
 > *.c are optimized by global optimizer.  We can identify API - what symbols
 > it exposes or references.  Modules are not only for dynamic loading.

That's a fine thing(*) but I *still* don't see how it relates to
splitting up conf/files.


(*) Although I think it'd be more trouble to maintain than it's worth.
Source modularity begins with structuring header files carefully, and
we've got a long, long way to go there before we're ready to think
about explicit linker-level ABI control.

 > > Given that config language has no scoping at all right now, the first
 > > order of business would be to add some of that, like
 > > 
 > > module vfs {
 > >    file kern/vfs_vnops.c
 > >    file kern/vfs_xattr.c
 > >      :
 > > }
 > 
 > It can be written as:
 > 
 >      define vfs
 >      file kern/vfs_vnops.c   vfs
 >      file kern/vfs_xattr.c   vfs
 > 
 > I don't see what's different.

The braces, which group the related material together and can be used
for scoping too?

 > > but putting each one of those in its own file isn't going to serve any
 > > purpose and it'll make everything that much harder to examine all at
 > > once.
 > 
 > Have you ever examined sys/conf/files?

Of course. Not only that, I've implemented quite a few kernel config
and build systems of my own, and I've waded into how it's done in
Linux as well.

% wc -l files
    1700 files

That's not small, but it's certainly not prohibitively large. Sure, it
could be organized better. I have no problem with that.

 > > Meanwhile, I think trying to wipe out all the boolean dependency logic
 > > in favor of a big graph of modules and submodules is also likely to
 > > make a mess. What happens to e.g.
 > > 
 > > file    ufs/ffs/ffs_bswap.c             (ffs | mfs) & ffs_ei
 > > 
 > > especially given that the ffs code is littered with FFS_EI conditional
 > > compilation? You can make ffs_bswap its own module, but that doesn't
 > > really serve any purpose. You could try making an FFS_EI module that
 > > works by patching the ffs module on the fly or something, and then
 > > include ffs_bswap.o into that, but that would be both very difficult
 > > and highly gross. You could compile two copies each of ffs and mfs,
 > > with and without FFS_EI support, but that wastes space. Or you could
 > > make FFS_EI no longer optional, which would be a regression.
 > > 
 > > (FFS_EI isn't the only such option either, it's just one I happen to
 > > have already banged heads with.)
 > 
 > Yes, we have to hunt all these dirtinesses.

Sure. But what do you propose to do about them? Whatever source file
list framework we have needs to handle these cases somehow. It's not
an improvement to "simplify" the framework so it can't handle the
cases we have to support.

 > One idea is to provide "alternative" modules.  Modules that provide/require
 > identical API, but have different signature (-DXXX, #ifdef).

Yes, that's the two-copies-each method.

-- 
David A. Holland
dholland%netbsd.org@localhost