Where should devctl notifications be sent from?

[Nik Clayton]

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.  /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.

> 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?

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 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.

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?
 
N
-- 
FreeBSD: The Power to Serve      http://www.freebsd.org/               (__)
FreeBSD Documentation Project    http://www.freebsd.org/docproj/    \\\'',)
                                                                      \/  \ ^
   --- 15B8 3FFC DDB4 34B0 AA5F  94B7 93A8 0764 2C37 E375 ---         .\._/_)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20040329/db7fee21/attachment.bin