I think that a proper
fix also requires a clear idea of the future of usbfs.  After all, at the bottom
of it, many of the locking problems come from a mal-adapted API.  One
thought I had was that the usbfs files (001 etc) could become directories.

Ideally, ones matching the sysfs names ... "usbfs2" will be a good thing to have, and 2.6 might make it easier than most folk suspect.


The directory would contain a subdirectory for each interface (for the
current configuration), and each interface directory would contain an
endpoint file for each endpoint of the current altsetting.  Sending an urb
to an endpoint would require opening that endpoint and writing to it ...

You could start experimenting with this pretty quickly. "libfs" makes it easy to arrange directory structure -- maybe start with one for an interface you claim -- and once you get rid of the nasty multiplexing of "usbfs", urbs map very nicely onto synchronous or asynchronous read/write calls. (See how "gadgetfs" does all that.)


          Configuration and altsetting changes would cause
directory contents to change.  What happens if you have an open endpoint
when a change deletes that endpoint?  Exactly the same thing that happens
with other file systems ...

Nobody expects The Principle of Least Surprise!



Backwards compatibility could be maintained by allowing the traditional
ioctl's on the top-level directory (001 etc).

Be more radical: a "usbfs2" goal should be to get rid of those! (Backwards compatibility could be maintained by coexistence too...)


Any objection to usbdev->serialize becoming a rwsem?

I suspect you mean to change more than that -- like having some tasks grab it as a (shared) readlock. When, and why?

- Dave




------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to