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>