On Tue, 15 Feb 2000, Michael Richardson wrote:

> 
>    (is there a better place than netbsd-help? )
> 
	Definitely :)

> >>>>> "David" == David Brownlee <abs@netbsd.org> writes:
>     David> 	We're currently looking at trying to get some of the good work
>     David> 	n reworking the autoconfiguration machinery done by a different
>     David> 	group of Japanese developers into NetBSD, which would make this
>     David> 	easier.
> 
>   Will this mean that loadable device drivers will be possible? I don't see
> any easy way get new nodes added to autoconf and have it do a new probe...

	One of the authors has posted to tech-kern (included at
	end of this message). I would suggest anyone interested
	follow up there.

	My initial goal was just to get a non locator packing
	version of config into the tree, so we can have a sane
	method of modifying config as a kernel boots, but if the
	dynamic config work is good, I don't see why NetBSD would
	not want it (but that is not my call :)

> ---------- Forwarded message ----------
> Date: Tue, 15 Feb 2000 20:05:07 +0900
> 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
> 
>   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