Re: config(5) break down

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

On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote:
 > > Well, first of all nothing says you can't read the whole file before
 > > resolving dependencies; there's nothing inherently wrong with
 > > 
 > > define foo: bar
 > >   :
 > > define bar: baz
 > >   :
 > > 
 > > I have no idea if config currently allows this but it's not exactly
 > > difficult to arrange.
 > 
 > I don't think it's worth.

Well, maybe. It seems like one of the things you're concerned about is
the maintenance overhead of making sure everything in "files" appears
in the right order. If you make it order-independent that goes away,
and "files" can be sorted by some more meaningful criteria.

That seems like generally a good idea.

 > Split *.conf files can be also distributed with *.[ch].  Its notation is
 > self-descriptive.  The only problem I'm aware of is it consumes more disk
 > space.

That and it becomes harder to find what you're looking for, which is I
guess what I'm mostly concerned about. It's already somewhat of a pain
to find any particular declaration in the various files.* files.

I think there are two reasonable ways to arrange it and we ought to
pick one and then hack on config itself until it works acceptably that
way.

These are:

(1) one big file, or as close to it as we can reasonably manage given
that we have all these different ports with different stuff;

(2) one file per source directory, like makefiles in a traditional
project.

The Linux folks after much pain and suffering finally settled on the
second way; however, their kernel build system uses recursive make
invocations so the structure all matches up.

The way the world works in NetBSD I tend to think one big file is
better. I'd even maybe argue that we should drop files.$(ARCH) in
favor of syntax, maybe something like

   if (ARCH == i386) {
      file    arch/i386/i386/autoconf.c
        :
   }

but perhaps not.

Still, I don't think one file per module (which given modular drivers
will tend to end up being one files.*/*.conf file per *.c file in many
parts of the tree) is a good idea.

 > > No, it seems like you're intending to use whole files to define groups
 > > instead of braces or some other punctuation. There is no need to split
 > > things into separate files just to show grouping.
 > 
 > True.

config already seems to use braces for declaring bus locators (or
something like that, probably not quite the right terminology) -- what
grouping syntax should we use? (Of course, the braces could be changed
if necessary; I count 579 uses but that's not really a major
massediting task.)

 > > (Besides, it's not necessarily as flat as all that, either.)
 > 
 > It's necessary to be flat to be modular.

Mm... not strictly. That's only true when there are diamonds in the
dependency graph; otherwise, declaring B inside A just indicates that
B depends on A. Consider the following hackup of files.ufs:

   file ufs/mfs/mfs_miniroot.c

   module UFS {
      option UFS_DIRHASH {
         flag opt_ffs.h
         file ufs/ufs/ufs_dirhash.c
      }

      option QUOTA {
         flag commandline
         file ufs/ufs/ufs_quota.c
      }

      file ufs/ufs/ufs_ihash.c
      file ufs/ufs/ufs_inode.c
      file ufs/ufs/ufs_lookup.c
      file ufs/ufs/ufs_bmap.c
      file ufs/ufs/ufs_vfsops.c
      file ufs/ufs/ufs_vnops.c

      file ufs/ffs/ffs_alloc.c
      file ufs/ffs/ffs_balloc.c
      file ufs/ffs/ffs_inode.c
      file ufs/ffs/ffs_snapshot.c
      file ufs/ffs/ffs_subr.c
      file ufs/ffs/ffs_tables.c
      file ufs/ffs/ffs_vfsops.c
      file ufs/ffs/ffs_vnops.c

      module FFS : filesystem {
         option FFS_NO_SNAPSHOT {
            flag opt_ffs.h
         }
         option FFS_EI {
            flag opt_ffs.h
            file ufs/ffs/ffs_bswap.c
         }
         option APPLE_UFS {
            flag opt_ffs.h
            file ufs/ffs/ffs_appleufs.c
         }
         option UFS_EXTATTR {
            flag opt_ffs.h
            option UFS_EXTATTR_AUTOSTART {
               flag opt_ffs.h
            }
            file ufs/ufs/ufs_extattr.c
         }
         ifoption WAPBL {
            file ufs/ufs/ufs_wapbl.c
            file ufs/ffs/ffs_wapbl.c
         }
         module MFS : filesystem {
            file ufs/mfs/mfs_vfsops.c
            file ufs/mfs/mfs_vnops.c
         }
      }

      module EXT2FS : filesystem {
         file ufs/ext2fs/ext2fs_alloc.c
         file ufs/ext2fs/ext2fs_balloc.c
         file ufs/ext2fs/ext2fs_bmap.c
         file ufs/ext2fs/ext2fs_bswap.c
         file ufs/ext2fs/ext2fs_inode.c
         file ufs/ext2fs/ext2fs_lookup.c
         file ufs/ext2fs/ext2fs_readwrite.c
         file ufs/ext2fs/ext2fs_subr.c
         file ufs/ext2fs/ext2fs_vfsops.c
         file ufs/ext2fs/ext2fs_vnops.c
      }

      module LFS : filesystem {
         option LFS_KERNEL_RFW {
            flag opt_lfs.h
            file ufs/lfs/lfs_rfw.c
         }
         file ufs/lfs/lfs_alloc.c
         file ufs/lfs/lfs_balloc.c
         file ufs/lfs/lfs_bio.c
         file ufs/lfs/lfs_cksum.c
         file ufs/lfs/lfs_debug.c
         file ufs/lfs/lfs_inode.c
         file ufs/lfs/lfs_itimes.c
         file ufs/lfs/lfs_segment.c
         file ufs/lfs/lfs_subr.c
         file ufs/lfs/lfs_syscalls.c
         file ufs/lfs/lfs_vfsops.c
         file ufs/lfs/lfs_vnops.c
      }
   }

I'm not sure why most of the ffs sources are currently declared "ffs |
lfs | mfs | ext2fs", but I haven't changed that.

Also note that QUOTA is currently not defflag'd (!) - I haven't
changed that either, although it seems like a bug.

 > > I thought you said all you needed to do was grep for the logical
 > > operators...
 > 
 > I said it's possible.
 > 
 > Again, I don't want to change config(1) at all.  And I don't need.

Well... changing it would probably be helpful. Ultimately we want the
right balance of changing config(1) and rearranging its input files.

I'm perfectly happy to rework the parser to support syntax like the
above if we can all agree on what it should be.

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