Subject: Re: Dumping autoconf info from DDB
To: None <firstname.lastname@example.org>
From: Atsushi Furuta <email@example.com>
Date: 02/15/2000 20:05:07
Hi, my name is Atsushi Furuta, one of FreeBSD/newconfig project.
From: David Brownlee <firstname.lastname@example.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. (email@example.com)
> 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
(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?