Date: Mon, 29 Mar 2004 22:34:37 +0100 From: Nik Clayton <nik@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: Where should devctl notifications be sent from? Message-ID: <20040329213437.GB713@clan.nothing-going-on.org> In-Reply-To: <20040328.011418.89945505.imp@bsdimp.com> References: <20040327085537.GC33016@clan.nothing-going-on.org> <20040328.011418.89945505.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 :-) > :=20 > : It looks like there are several places where the devctl_queue_data() and > : related calls could be placed: > :=20 > : 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 >=20 > 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=20 '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? =20 It makes sense if devd is going to be the OneTrueWay to control this sort= =20 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= =20 to expose these events that applications can monitor, instead of multiple different mechanisms? =20 N --=20 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 --- .\._/= _) --8GpibOaaTibBMecb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaJZsk6gHZCw343URAj2vAJsGFv1kcGuUIQab7cROk/lK4Mst/QCdH4rk pIISJ6lOZSVxfRRo4zxpLb4= =yj00 -----END PGP SIGNATURE----- --8GpibOaaTibBMecb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040329213437.GB713>