Date: Tue, 30 Mar 2004 17:00:05 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Nik Clayton <nik@freebsd.org> Cc: arch@freebsd.org Subject: Re: Where should devctl notifications be sent from? Message-ID: <Pine.NEB.3.96L.1040330165148.93169Q-100000@fledge.watson.org> In-Reply-To: <20040327085537.GC33016@clan.nothing-going-on.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Mar 2004, Nik Clayton wrote: > Apologies in advance if this is too trivial for -arch. > > I'm trying to work out where it's appropriate to add devctl > notifications. > > 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 > geom(4) -- when geom creates the device (/dev/da2 (and da2s2) in my > case). Robert Watson has a patch that implements this. > devfs -- specifically, in make_dev(9) and destroy_dev(9) > > The limited research that I've done suggests that the most generic place > to put this code is inside make_dev(9) and destroy_dev(9). But this > seems so trivial that I can't believe no one else hasn't done the work, > so I figure there's probably something important that I'm missing. I think all of those are interesting choices, but let me give you my spiel on why I think GEOM is a good place to start. We have many different object namespaces in the kernel, based on the different subsystems and abstractions present there. For example, "fxp" is the name of a newbus device attached to (potentially) a PCI bus. It's also the name of a network interface device attached to the ifnet mechanism. It's also a device node in /dev. Likewise with storage devices, which can appear at many layers. We currently have a bogosity in devd: with ethernet devices, we run dhclient on an interface based on the interface attaching to newbus, not the interface arriving at the network layer. Likewise, if you write an automounter based on what's there today (the newbus event), there's actually a potential race or weakness: a device attaching to newbus doesn't mean it's ready for disk I/O. What I'd like to see happen is the notion of "subsystem" or "class" be introduced to the devctl namespace. Off the top of my head, the classes I'm interested in would be "newbus" (device attachment), "geom" (disk objects), and "ifnet" (network interface objects), and perhaps "devfs" (entries in /dev). The same name appearing at different layers has different interpretations, and requires different activities. Likewise, an object may exist only at a few layers (network pseudo-interfaces don't appear in newbus, for example; likewise, layered storage abstractions). There's another benefit to doing this: it becomes easier to write things like automounters and network interface handlers in userspace because class information is exposed from the kernel. Instead of "/dev/foo arrived", you get "A network interface named fxp0 has arrived"; likewise, instead of "/dev/foo has arrived", you get "A storage device named ad0.gbde has arrived". This makes it a lot easier to decide whether you should run dhclient (no need to hard-code interface names in devd.conf) or whether you run the automounter (no need for the auto-mounter to try and see if /dev/mem is a disk). There are other approaches that could be taken -- for example, newbus could learn to incorporate much more stuff (all stuff). However, that's a much more complex answer, requiring a lot of implementation changes in a lot of critical subsystems. Adding a new field to /dev/devctl's output is almost a no-op in complexity, and buys us a lot. It also helps us avoid answering the question you posed: we don't have to identify The One True Place, instead, we let important subsystems announce events in a way that makes sense for them, in their own namespace. Sure, you get a few more events (different layers reporting a related event), but you actually get a lot more information, and in a much more useful way. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040330165148.93169Q-100000>