Re: Devd event from GEOM?

On Tue, 25 Jan 2005, Warner Losh wrote:

> > > 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.
> 
> And for the network case there's a lot more interesting than 'the device
> is there'.  I want to only run dhclient on interfaces that have carrier,
> are in this ssid, etc.  This information is presented via the routing
> sockets, but not via the device.

It depends a bit on where we sit: we probably want a neteventd that knows
about this sort of thing and performs unified network interface
management.  In the mean time, I just want dhclient launched, because
dhclient already knows about ssid's, link state, etc. 

> > 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).
> 
> I's suspect that da0 would arrive in GEOM before newbus.  newbus
> generates its arriveal events after the device has completed its
> attachment.  Part of the attachment is to add it to GEOM.  This may or
> may not be done asynchronously to the newbus addition.  Network adapters
> are done synchronously in our present implementation, so by the time the
> newbus attach finishes, the network interfaces in the network namespace
> are necessarily available (assuming they haven't just disappeared). 
> 
> The problem I see with exporting GEOM events is that you still need some
> kind of smarts on the receiving end to know if you are dealing with an
> interesting GEOM thing, or an uninteresting one... 

The idea behind the class information is that the application can use a
combination of the class, name, configuration data, and direct
communication with the object to do useful things.  However, to
communicate with an object today, you first need the class information,
which is why you want it early as part of the event notification.

Robert N M Watson