From owner-freebsd-arch@FreeBSD.ORG Mon Mar 29 14:22:51 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 3EC0516A4CE; Mon, 29 Mar 2004 14:22:51 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8563643D46; Mon, 29 Mar 2004 14:22:50 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i2TMMnkj096214; Mon, 29 Mar 2004 15:22:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 29 Mar 2004 15:22:57 -0700 (MST) Message-Id: <20040329.152257.88472911.imp@bsdimp.com> To: nik@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040329213437.GB713@clan.nothing-going-on.org> References: <20040327085537.GC33016@clan.nothing-going-on.org> <20040328.011418.89945505.imp@bsdimp.com> <20040329213437.GB713@clan.nothing-going-on.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 22:22:51 -0000 In message: <20040329213437.GB713@clan.nothing-going-on.org> Nik Clayton 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