Messages in this thread | | | From | (H. Peter Anvin) | Subject | Re: [linux-usb] Re: USB device allocation | Date | 9 Oct 1999 05:48:43 GMT |
| |
Followup to: <yd8oge9l2cd.fsf@hoshi.engr.sgi.com> By author: Scott Henry <scotth@sgi.com> In newsgroup: linux.dev.kernel > > >>>>> "T" == Theodore Y Ts'o <tytso@MIT.EDU> writes: > > T> However, even if you use this type of approach for /devfs, it's still a > T> cumbersome interface. Consider that with a /proc/devices-style > T> approach, a one or two read()'s will allow you to get all of the > T> information you need. > > T> With a /devfs approach, you will still need to readdir() through all of > T> /devfs, figure out what changed, and then stat the device to see what > T> has differed. > > The current devfs patches have a special device file (/dev/.devfsd) > for devfsd to listen to for changes. It doesn't have to scan the > /dev directory for _that_ reason. At least that's what the docs say-- > I haven't looked at the code. >
I think a device daemon makes a lot of sense, as does a standard kernel notification mechanism for it. I do make the observation that if you have a device node management daemon, there is no need for the virtual device filesystem. devfsd (devd) *does* make a lot of sense; it is the rest of the filesystem that doesn't. What I would like to see is devd, but operating on a physical filesystem where data can be retained.
-hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |