Re: Devd event from GEOM?

On Tue, 25 Jan 2005, Poul-Henning Kamp wrote:

> In message <Pine.NEB.3.96L.1050125143745.3036A-100000_at_fledge.watson.org>, Robert Watson writes:
> 
> >We're really not interested
> >in the newbus announcement, since there are lots of network interfaces
> >that have no physical representation and so aren't visible to newbus.
> 
> I think this is the crux of the matter. 
> 
> newbus events will mostly be able tell us that we need to load a driver
> kld.
> 
> devfs events on the other hand tells us that something can be accessed
> from userland.

... Except for the synthetic objects that don't have device nodes. :-) 

> Since we added /dev/net/* we have sort of collapsed the split we
> previously had where some devices did not appear in /dev. 

The net device nodes were added for one purpose: to allow Kqueue to attach
to a network interface, as kqueue requires a file descriptor.  And most of
the network developers I've talked to think this was probably a design
error.  Note that the network stack has a fairly complex event system
already -- routing sockets, which express a spectrum of network-related
events including, but not limited to, interfaces appearing and
disappearing.  Adding /dev/net entries added multiple paths to the same
ioctl() mechanism, complicated the network interface allocation path
substantially (introducing more races), etc.  I'd much prefer we got rid
of them, if we can.

> There are still virtualized cases though, adding more hardware under
> opencrypto comes to mind.  I can't really turn that into an example
> where we need to do more than respond to newbus by loading the driver.
> 
> But as I said in the other email, we should probably have devfs
> communicate the type of device to devd to save some rather complex code
> in userland.  (The regexp matching all our ethernet drivers in devd.conf
> have always irritated me).

We have all the information in the kernel ("I found a device", "it was a
SCSI disk", "and we can store bytes on it!", "and it has partitions!") --
that we're not exposing it to user space means that we're doing far too
good a job of hiding quite accessible information.  If the information is
bundled up neatly for delivery so that the layer relationships are clear
-- fine, although I don't think that will be possible in every case (i.e.,
da0 arriving in newbus and GEOM may be simultaenous, but we might not have
finished probing da0s1a.foobar for quite a bit later).

Robert N M Watson