Here's a message that was posted earlier this year about this
subject. The source patches I saw from Uchiyama indicate
some progress / rewrites since then, so I'm not sure how
up-to-date this information is, but I'm posting it here
to avoid duplicate effort.

- Frank

----- Forwarded message from Atsushi Furuta <furuta@sra.co.jp> -----

To: abs@netbsd.org
Cc: soda@sra.co.jp, tech-kern@netbsd.org, uch@netbsd.org
Subject: Re: Dumping autoconf info from DDB
In-Reply-To: <Pine.NEB.4.21.0002111912110.22416-100000@oblivion.mono.org>
Date: Tue, 15 Feb 2000 20:05:07 +0900
From: Atsushi Furuta <furuta@sra.co.jp>

  Hi, my name is Atsushi Furuta, one of FreeBSD/newconfig project.

From: David Brownlee <abs@netbsd.org>
Date: Fri, 11 Feb 2000 19:21:51 +0000 (GMT)

> > > > Newconfig project of japanese freebsd people tried to solve this
> > > > problem by extending NetBSD configuration mechanism dynamically.
> > > > (adding new drivers and new buses completely dynamically was also
> > > >  one of their goals.)
> > > > 
> > > 	This looks quite interesting - does their overall approach
> > > 	seem compatible with NetBSD? If so, would they be interesting
> > > 	in coordinating with pulling something like this into the
> > > 	main NetBSD tree?
> > 
> > As far as I know, Yes.
> > Furuta, Uchiyama, Maekawa and Kanaoka said that they are interested to 
> > complete their work on NetBSD.
> > 
> > P.S.
> > Uchiyama already has developer's account of NetBSD. (uch@netbsd.org)
> 
> 	What would be the best method to assist them in this - would
> 	Furuta, Maekawa and Kanaoka also be interested in NetBSD
> 	developer access?

  At least, I subscribe for tech-kern.  I hear Maekawa and Kanaoka
subscribe, too.  I think it should be discussed in this list.

> 	Before embarking on such a project it might make sense to
> 	ask the existing NetBSD developers to look at a general
> 	overview of the design to ensure there is no later conflict.

  Agree. I will discuss with NetBSD developers on the design policy of
dynamic configuration. I think the implementation in newconfig project
for FreeBSD is just tentative and probably has many bugs.

  As a starting point, please let me explain about our dynamic
configuration design.

	(1) In dynamic configuration, we should also provide all
	    functions of the config(8), just like a "file" search
	    path, conditional linking, unit number wiring, and so on.

	(2) We should provide same syntax for static configuration and
	    dynamic one. Static configuration by config(8) has two
	    category of syntax, "files" file and configuration file,
	    so we should provide both in dynamic way.

	(3) To allow binary packaging by third party, we should change
	    device driver trees dynamically. The device driver trees
	    are not only device instance tree, but also "files" file
	    based tree and configuration file based tree. Strictly
	    speaking, "files" file tree and configuration file tree
	    are not really trees. They are DAGs rather than trees.

	    Dynamic "files" file fragment should be provided by the
	    developer of the drivers. Dynamic configuration file
	    fragment (or equivalent) should be given by user.

  Current implementation of config(8) read "files" file and config
file, builds two DAGs, check config DAG against "files" DAG, pack
config DAG, emit config DAG as struct cfdata and give up "files" DAG.
As soda mentioned, to achieve our goals, we require "files" DAG in
kernel (or runtime agent), too.

  We make config(8) emit unpacked internal DAG data.  Now kernel knows
"files" DAG information. config(8) also used to make "dynamic module",
which read files file and config file and create Makefile and DAG
information for package. "files" information handling routines in
kernel is also implemented as sys/subr_config.c.

  Would you give me any comments?
-- 
furuta@sra.co.jp

----- End forwarded message -----