Re: config(5) break down

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