Re: config(5) break down

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

On Fri, Mar 05, 2010 at 11:45:20AM +0900, Masao Uebayashi wrote:
 > > See, this is the part that I don't understand. You're talking about
 > > normalizing logic, which is fine, and making shared files first-class
 > > entities, which is fine too though could get messy.
 > 
 > I have no idea how normalized *.conf files can be messier than
 > sys/conf/files we have now.

A few hundred little tiny files scattered all around the tree? It
could get very messy.

 > > But then suddenly you jump into splitting up files.* into lots of
 > > little tiny files and I don't see why or how that's connected to what
 > > you're trying to do.
 > 
 > It looks sudden to you, because we've long had the monolithic
 > sys/conf/files.
 > 
 > Why have we had that messy big file?  What is the justification of
 > having random piece of definitions in one file and manage its
 > dependencies by hand? Who maintains it?
 > 
 > To manage a complex system which is made of many components which
 > depend on each other, we usually split the thing into modules and
 > write dependencies.  Like *.c and *.h files, /etc/rc.d, pkgsrc,
 > etc. If you claim that splitting sys/conf/files is a bad thing,
 > you'd consider to concatenate all the *.c / *.h files in the
 > sys/kern too?

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.

I don't see that every loadable module needs to have its files.*
declarations in a separate file, any more than every function needs to
be defined in a separate source file.

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
     :
}

module ufs: vfs {
   file ufs/ufs/ufs_bmap.c
   file ufs/ufs/ufs_inode.c
     :
}

module ffs: ufs {
   file ufs/ffs/ffs_alloc.c
   file ufs/ffs/ffs_balloc.c
     :
}

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.

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.)

 > The reason why sys/conf/files is that big now, I guess, is that people don't
 > know how to write config(5), which I've figured out for the first time
 > on the earth.

That's probably true, but I still don't see how reorganizing it and
making the language more powerful requires slicing the file into a
zillion tiny pieces.

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