Re: config(5) break down

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

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

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

> 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?

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

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

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635