Where should devctl notifications be sent from?

[M. Warner Losh]

In message: <20040329213437.GB713 at clan.nothing-going-on.org>
            Nik Clayton <nik at freebsd.org> writes:
: On Sun, Mar 28, 2004 at 01:14:18AM -0700, M. Warner Losh wrote:
: > : The specific problem I'm trying to solve involves an iPod connected
: > : through firewire.  I'd like to be able to have devd be notified when the
: > : iPod arrives, so that various processes can kick off automatically.  In
: > : an ideal world, I'll drop the iPod in the dock, and some backup
: > : processes start, thereby allowing me to justify the purchase of a model
: > : several sizes larger than I actually need :-)
: > : 
: > : It looks like there are several places where the devctl_queue_data() and
: > : related calls could be placed:
: > : 
: > :     firewire(4) -- when the device is plugged in
: > :     fwohci(4) -- when the interface arrives
: > :     sbp(4) -- when it's recognised as a mass storage device
: > 
: > These are all inapprorpiate.  The devctl_queue_data is already called
: > from the bus level for these device.  Either there is a driver, in
: > which case a driver added is called, or there isn't, in which case the
: > no driver routine is called.
: 
: If I'm following, that means I should be able to:
: 
:     # cat /dev/devctl
: 
: drop the iPod in the dock, and see various '+' lines?  I've just tried
: that, and there's no output.

Only if devd is not running.  I know for a fact that they will appear,
since I've loaded firewire drivers while I had a camera connected, and
all the right goo happened.

: /var/log/messages shows entries from
: firewire0 and fwohci0, devfs has created /dev/da2 and /dev/da2s2, and 
: 'mount /ipod' works, so the firewire driver's doing the right thing as
: far as recognising and enabling the device goes.

Unless you don't have devd running, this isn't the case.  And if you
don't have devd running, chances are excellent that it is disabled in
the kernel.

hw.bus.devctl_disable: 0

is the key.

: > This is clearly wrong.  devd will soon grow the ability to do actions
: > based on files appearing in a directory tree.  Since /dev is a
: > directory tree, that will be a more appropriate way of dealing.  devd
: > does not know about dev_t things from the devctl interface, nor should
: > it in my opinion.  However, the tree stuff should be sufficiently
: > general to do what you need (and may obviate the need for robert's
: > patches, since geom name space is a subset of dev by convention).
: 
: Yep, that would work.  So devd is going to be monitoring /dev/devctl for
: device notifications, and directories (e.g., /dev) for other events.
: What about things like EVFILT_NETDEV for things like link up and link
: down events?

Yes.  That's the plan.  There will be a variety of different events.

: Playing devil's advocate for a minute (and I'm still wrapping my head
: around all this), is that the right way to go?  

It is how I designed it from day one.

: It makes sense if devd is going to be the OneTrueWay to control this sort 
: of thing, but if we might want different devd-alike implementations
: (maybe something with a GUI on top), each devd-alike is going to have to
: start monitoring these other event sources too.

No.  That's not going to be the case.  devd will republish to a pipe
so that we don't have to add a number of different weird things into
the kernel.

: Wouldn't it be better to have a single place (or mechanism) for the kernel 
: to expose these events that applications can monitor, instead of multiple
: different mechanisms?

No.  It would be better to have one daemon that deals with all the
stuff and republishes it over a single pipe.

Warner