Re: config(5) break down

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Mon Mar 08 2010 at 07:09:07 +0000, David Holland wrote:
> 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.)

This one is easy, no need to make it difficult.  The NetBSD-supplied
module is always compiled with FFS_EI (if you don't like it, you can
always compile your own just like you can compile your own kernel now).
We don't care about mfs here, since it's not reasonable to want to mount
a memory file system in the opposite byte order (technically I guess you
could mmap an image instead of malloc+newfs and then mount(MOUNT_MFS),
but you might just as well use ffs).

Things like wapbl are currently an actual problem, since it is multiply
owned (conf/files *and* ufs/files.ufs).  The easy solution (and my
vote) would be to make vfs_wapbl.c always included in the base kernel.
If someone feels it's worth their salt to make it into two modules with
all the dependency hum-haa, that would be a good place to start practicing
instead of ffs_ei.