From owner-freebsd-arch@FreeBSD.ORG Mon Mar 29 13:34:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09DF316A53B; Mon, 29 Mar 2004 13:34:48 -0800 (PST) Received: from crf-consulting.co.uk (82-44-220-218.cable.ubr10.haye.blueyonder.co.uk [82.44.220.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53CD243D49; Mon, 29 Mar 2004 13:34:47 -0800 (PST) (envelope-from nik@crf-consulting.co.uk) Received: from clan.nothing-going-on.org (clan.nothing-going-on.org [192.168.1.20])i2TLYb5U062221; Mon, 29 Mar 2004 22:34:37 +0100 (BST) (envelope-from nik@catkin) Received: from clan.nothing-going-on.org (localhost [127.0.0.1]) i2TLYbuv025391; Mon, 29 Mar 2004 22:34:37 +0100 (BST) (envelope-from nik@clan.nothing-going-on.org) Received: (from nik@localhost)i2TLYbbA025390; Mon, 29 Mar 2004 22:34:37 +0100 (BST) (envelope-from nik) Date: Mon, 29 Mar 2004 22:34:37 +0100 From: Nik Clayton To: "M. Warner Losh" Message-ID: <20040329213437.GB713@clan.nothing-going-on.org> References: <20040327085537.GC33016@clan.nothing-going-on.org> <20040328.011418.89945505.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline In-Reply-To: <20040328.011418.89945505.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i Organization: FreeBSD Project cc: arch@freebsd.org Subject: Re: Where should devctl notifications be sent from? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 21:34:48 -0000 --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--