Re: [linux-usb] Re: USB device allocation

Alex Nicolaou (anicolao@mud.cgl.uwaterloo.ca)
Thu, 07 Oct 1999 17:11:32 -0400

"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/