Re: Devd event from GEOM?

On Tue, 25 Jan 2005, M. Warner Losh wrote:

> : > : Since they constitute different "things" with quite different management
> : > : properties.  This also provides additional contextual information: rather
> : > : than devd having to guess what type of object a device node is using name
> : > : matching, by learning about it through geom or the network stack, it knows
> : > : what kind it is up front in a strong way. 
> : > 
> : > While I tend to agree, I do think that GEOM is the wrong layer to
> : > announce things from.  The more correct layer would be /dev, since you
> : > are again assuming that a GEOM that's created with name foo is
> : > accessible via /dev/foo. 
> : 
> : So suppose I'm listening to a devd socket to try and identify storage
> : devices arriving that I can automount.  How do I know which device
> : announcements are for storage devices?
> 
> Hmmmm, once upon a time I'd have said 'stat the device, and you know'
> since those would be block devices....  The trouble is that we don't
> know at that level either, yet when the GEOM even happens, how can we be
> sure that we win that race? 

What I'm basically suggesting is that the class of the device, when
announced, should be included in the announcement, and that that
information is already present.  We have all that information in the
kernel, there's no reason to discard it when announcing to user space in
the name of giving all devices equally poor handling :-).  I.e., when GEOM
announces a device to devd, we know aprior that it's a storage device;
likewise, when the network stack announces a network interface to devd, we
know apriori that it's a network interface.  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.e., I see it as a feature, not a bug, that the following event streams
might arrive for a device monitoring application:

  newbus: hey, I got ugen0!
  devfs: hey, I got ugen0!
  newbus: whoa, ugen0 morphed into ums0 after you loaded that funky .ko
  devfs: whoops, I lost ugen0!
  devfs: hey, I got ums0!

  newbus: hey, I got fxp0!
  ifnet: hey, I got fxp0!
  devfs: hey, I got net/fxp0!

  ifnet: hey, I got vlan0!
  devfs: hey, I got net/vlan0!

  ifnet: hey, I got gif0!
  devfs: hey, I got net/gif0!

  newbus: hey, I got da0!
  geom: hey, I got da0!
  geom: hey, I got da0s1!
  geom: hey, I got da0s1a!
  devfs: hey, I got da0!
  devfs: hey, I got da0s1!
  devfs: hey, I got da0s1a!

  devfs: hey, I got ttyp0!
  devfs: whoops, I lost ttyp0!

dhclient doesn't care about the arrival of the newbus fxp0 attachment, or
the devfs node net/fxp0 (which many consider a bug anyway), it cares only
about the ifnet attachment, since the vast majority of network tools use
ioctl() and BPF to manage interfaces.

automountd cares primarily about the dual arrival of the GEOM device and
the similarly named devfs entry.  It doesn't care about every entry in
devfs, it really just wants the GEOM entries.

Given that the devfs nodes are really quite uninteresting from a network
stack perspective, and may also be uninteresting for other device types
(for example, newbus attachment by devices that don't have device nodes),
I'd rather not tie the ability to monitor for events to having a /dev
entry.  Likewise, newbus is not involved in the attachment of all
interesting devices -- above are two examples (synthetic device nodes,
network interfaces) where newbus events are not useful.  The above
information stream gives me precisely what I want if I'm writing a network
management daemon, an automounter, etc.

Robert N M Watson