Messages in this thread | | | Date | Thu, 07 Oct 1999 17:11:32 -0400 | From | Alex Nicolaou <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
"Theodore Y. Ts'o" wrote: > Date: Wed, 06 Oct 1999 11:37:31 -0400 > From: Alex Nicolaou <anicolao@mud.cgl.uwaterloo.ca> > > "Theodore Y. Ts'o" wrote: > > I claim that there are better interfaces than readdir() + > > stat() and a dynamic filesystem in order to pass this information to > > userspace, though, and I hope most people would agree with me. Why > > don't we try to design that interface first, and I suspect the rest will > > follow relatively easily. > > Can you propose a better interface? I don't really understand your > comment, because the UNIX filesystem has always been the namespace > for operating system objects.... [snip] > A much better interface for getting the information out to the daemon in > one fell swoop would be something like /proc/devices (except we would > want to list the minor and major mode devices). There would also need > to be an interface where a user-mode daemon could be informed of > changes; some kind of synthentic file which the daemon could select() or > poll(), and read() from to find new devices. Surely this is better than > forcing the daemon to periodically run readdir() over all of /devfs > looking for new devices!
My original post was meant to suggest that your proposed notification method is not the right interface. There's a generic problem with the UNIX fs design that there is no way to be notified when an inode changes, and I think this problem could/should be fixed in a way that allows any process to be notified of a change in an inode specified by the application. Then you could wait for changes in /devfs or wait for changes in /proc/devices and act on them. (Meanwhile GUI file managers could efficiently display up-to-date directories without requiring a manual refresh or wasting cycles calling readdir() repeatedly.)
I think I misunderstood your post to be suggesting that we not provide the device functionality via the filesystem, but rather use a different interface. However, now I misunderstand your post to mean that you just don't want to name it /dev and administer it with /devfs but would rather name it /proc/devices and administer it a different way, while living with the limitations of the existing interfaces. I think my confusion stems from the use of the word "interface" to describe the overall way of interacting with devices as opposed to meaning specific system calls...
I personally don't care much about which solution to this particular problem is actually chosen. However, I think that the ability to know when an inode is modified makes the problem easier to solve no matter which solution is used for the devices issue, as well as solving other, "unrelated", problems.
alex
- 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/
| |