Subject: Re: Dumping autoconf info from DDB
To: Atsushi Furuta <email@example.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 02/15/2000 14:31:32
On Tue, 15 Feb 2000, Atsushi Furuta wrote:
> Hi, my name is Atsushi Furuta, one of FreeBSD/newconfig project.
Please to meet you, I'm David - I try to encourage things to
happen, but others will make the real decisions :)
> From: David Brownlee <email@example.com>
> Date: Fri, 11 Feb 2000 19:21:51 +0000 (GMT)
> > 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?
I'm not the best person to comment (but I've referenced this
on netbsd-developers in the hope that any interested parties
can check here).
The first stage of making config emit unpacked DAG data is
needed for any 'manually tweak config as kernel boots' tool,
so is a good thing to have in any case.
If I am a third party wanting to produce a module in this
senario, I would ship source of object files, plus a files
fragment and a config fragment? I would run config(8) with
appropriate options on the config fragment and it could
load itself into the running kernel? (Apologies if I am
Would this also replace lkms?