cvs commit: src/sbin/kldunload kldunload.8 kldunload.c

[Robert Watson]

On Tue, 13 Jul 2004, M. Warner Losh wrote:

> : >newbus definitely supports multiple inheritance like you describe.
> : >Just use DEFINE_CLASS_2 for objects A and B and list X and Y for the
> : >first one and Y and Z for the second.
> : 
> : That was another thing I ran into with newbus: I had to define
> : things at compile time which I only knew at (auto-)configure time.
> 
> Which things? 

If I might suggest -- this is not the right mailing list for a discussion
of how to make most of FreeBSD's kernel features fit the Newbus
architecture.  Probably the arch@ mailing list is the place to do that.

That said, I'm not sure I see the kldunload state changes as incompatible
with the notion of having most kernel modules become newbussified,
especially given that there are a lot of kernel extension interfaces (many
of which were named by Poul-Henning), and many of which would benefit from
a safe unloading mechanism without having to substantially modify them in
the mean time.  The primary goal, presumably, would therefore be to make
sure that the KLD interface was semantically compatible with the Newbus
model, and not that it not exist. 

I suggest creating a thread named "Newbus the world" on arch@, in which
the major classes of kernel modules and extension interfaces are
documented, along with ideas about how they could usefully turn into
Newbus-enabled pieces.  Poul-Henning's list is a decent starting point,
but probably not a complete list.  Remember to tell people why switching
to Newbus would be an improvement, especially for modules and module
systems that don't clearly map onto synthetic or real devices, such as
Netgraph nodes, MAC policy modules, schedulers, network protocols, file
systems, etc.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research