Re: config(5) break down

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Fri, Mar 12, 2010 at 4:31 AM, David Holland 
<dholland-tech%netbsd.org@localhost> wrote:
> 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:

There're diamonds (for example, ppp-deflate depends on ppp and zlib).

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

In this plan, what *.kmod will be generated?

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

So you're proposing a syntax change without understanding the existing
syntax?  (You don't know what braces are for, you didn't know "define"
behavior, ...)  I have to say that your proposal is not convincing to
me...

Masao