Re: Devd event from GEOM?

On Tue, 25 Jan 2005, Warner Losh wrote:

> > 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 don't neet yet another daemon around for that.

Ah, but we do, because whatever daemon it is needs to provide unified
management of routing in the presence of multiple DHCP and link locally
configured network interfaces.  I.e., when I'm switching between wireless
and wired networks, Useful Things Should Happen, and this can't currently
be properly managed by today's dhclient.  Likewise, I want to always have
link local addresses configured for every network interface, and not have
things like dhclient step on them.  This requires dhclient to become
substantially more mature and/or grow a lot, or it requires a new daemon. 
Having many daemons is just asking for them all to step on each other's
toes, adding and removing addresses and routes in ways that leaves me with
nothing useful to network with, requiring user intervention.  If you've
ever used a FreeBSD box in this scenario, followed by a Mac OS X box,
you'll know what I mean.  Neither is perfect, but the one with centralized
configuration management does a much better job :-).

> > 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.
> 
> Right now we can't even get the class information out of the userland
> interfaces we have.  We should correct that problem, rather than
> complicate things prematurely because it is expedient to do so today. 

I think we're talking past each other: the devctl format has a field for a
class.  I simply modified GEOM to expose its events using devctl,
identifying its class as GEOM.  That is, everything we needed was there,
except the kernel hadn't quite provided enough information.  If we want to
layer it slightly differently and have it exported by devfs to devctl
based on a property of the cdev, that's fine by me also.

Robert N M Watson