DragonFly BSD
DragonFly kernel List (threaded) for 2004-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Request for Feedback: proposed config(8) improvement

From: Chris Pressey <cpressey@xxxxxxxxxxxxxxx>
Date: Sun, 7 Mar 2004 11:41:38 -0800

On Sun, 7 Mar 2004 00:21:18 -0500
David Rhodus <drhodus@xxxxxxxxxxx> wrote:

> Why not just try and fix the config(8) problem with the
> ultimate solution that has been pending for a long time
> and that is to work on the removal of config(8).
> -DR

OK - apologies if I misinterpreted you, Dave.  I thought by "pending"
you meant someone was actively working on it.

And I guess I see what you mean, except my opinion would be that it's
not config(8) itself that's any sort of problem, it's the system of
"kernel parts" surrounding config(8) - which is more or less what I'm
looking into.

At this point, I think the "kernel parts" need to expose a consistent
interface to a) each other and b) the rest of the system.  The simplest
way forward is probably to make all device drivers modules (even if they
are "static modules" that can't be loaded/unloaded.)

The infrastructure of macros for putting metadata onto modules has been
there for a while, but the assumption is (I think) that the only place
this metadata needs to go is into .ko files.

Unfortunately, that's not true if you want to use that information to
orchestrate a kernel build - because the .ko modules aren't built yet. 
:)  Some simple rules of thumb about the proper use of MODULE_DEPEND and
friends might be all that is needed, to start.

But config(8) itself is sort of incidental.  Sure, it could be replaced
(probably by a couple of clever Makefiles and awk scripts,) but OTOH it
could easily be adapted to a new device infrastructure too.  I'll
definately give some thought into replacing it with make(1), because
that would give it some things "for free" (like dependency checking.)


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]