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 dholl...@netbsd.org