Date: Wed, 28 Nov 2001 13:03:58 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Josef Karthauser <joe@tao.org.uk> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, mjacob@feral.com, arch@FreeBSD.org Subject: Re: Anybody working on devd? Message-ID: <Pine.NEB.3.96L.1011128125713.40174B-100000@fledge.watson.org> In-Reply-To: <20011127114133.S643@tao.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Nov 2001, Josef Karthauser wrote: > Devices that come and go can come and go quickly. For instance a USB > sync'd palmpilot only appears as a usb device once the hotsync button > has been pressed, and disappears once the sync process has finished. A > userland process that wants to sync has to wait until it sees the usb > device node appear to know that it is there (unless usbd can fire the > process off at enumeration time). If a userland process pokes with the > node permissions sometime after the device node appears, there's a race > between the application and the userland devd. Sometimes the sync will > succeed, sometimes it will fail due to wrong dev node permissions. > > For this reason I'd prefer the devnode to be created with the right > permissions in the first place. Phk was talking about loading > user/group policies into the kernel so that make_dev can use them whilst > creating the node. Note that the race can be fixed by modifying your source of events for "the common application". Hence my recommendation (made after your post, as I caught up) that devd/devfsd feed off of a /dev/somethinginparticular, and that they generate event information on /dev/somethingmoregeneral, giving the daemon an opportunity to do whatever it wants before consumers leap for it, or rather, allowing consumers to wait for a formal notification that the device is ready before using it. Note that if you were processing new serial devices (usb ones, say) using stty before use, you'd have similar requirements. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011128125713.40174B-100000>