Alan Stern wrote:
On Thu, 15 Jan 2004, Greg KH wrote:
We really
need to start over and make usbfs2. It should look something like the
gadgetfs interface.
What about backward compatibility?
How much is needed? Remember that usbfs1 and usbfs2 need to
coexist for a while. What "usbfs1" APIs should carry forward
to a "usbfs2-only" world, if any? It's rather ioctl-abusive.
I think before anyone dives into implementation on "usbfs2" it'd
be worth hearing peoples' ideas on what it should do. Not so much
"how it should do it" if possible ("use libfs", "api like this", etc)
but more at the level of functional requirements, including any
backwards compatibility.
The one thing I keep hearing about is a file-per-endpoint I/O model.
So that read()/write() calls can be used. And using AIO to replace
the usbfs-specific async request model ... that can get rid of quite
a lot of "usbfs1" problems right away. (Those are both things that
"gadgetfs" supports.)
But there's more to "usbfs1" than that. Stuff like device discovery,
lifecycle (including driver bind/unbind) and access control; "usbfs2"
will need analogues for all that. And likely a few other things that
applications would like to have had with usbfs. That's all stuff that
I don't think can be borrowed from gadgetfs, since the two sides see
different events and can't have identical responses.
Here are some questions that come to mind. I don't claim to
know the answers to many, or even most, of these.
* How about usermode APIs? "libusb" and "usb(dev)fs" are
essentially what C programmers use, and there's some
notion of portability to non-Linux systems. I'm not
sure it's realistic to try helping BSD implement usbfs2.
Also, a C-only framework is undesirable. (Minimizing
use of ioctl will be a big win for non-C programming.)
* How about UI/commandline tools? If users can't browse
usb devices easily with "usbfs2" I have a hard time
imagining everyone converting. "usbutils" may well need
replacement. Maybe sysfs is what should be browsed.
* How should this relate to "udev"? One implementation
strategy would make "usbfs2" endpoint files be regular
character devices. There are other strategies too,
including not coupling them at all.
* How should this relate to "sysfs"? I kind of like the
idea of having the "usbfs2" directory structure match
sysfs. If the two are linked effectively, then all
of the /proc/bus/usb/devices functionality should be
coming from sysfs. (Except, see the next point.)
* How should non-current configurations be exposed?
Right now they're not visible through sysfs in the
way they're visible in /proc/bus/usb/devices. It may
be just fine to say that usermode code must issue
the control requests itself.
* How should interfaces be presented? My initial guess
is as directory, with files for each endpoint in the
active altsetting and likely one for ep0 ... at least,
interfaces claimed by "usbfs2" could look that way.
If they're claimed by some kernel driver, or aren't
claimed at all, I'm not sure if they should appear.
(Other than in sysfs.) We should still have the
ability to let usermode code control what kernel driver
is bound to which interface.
* How much should "usbfs2" really be part of "usbcore"?
I think some per-device capabilities (fetching config
descriptors, for one) should exist even when no user
mode driver is talking to any device interface.
Couldn't we make "usbfs2" just probe()/disconnect()
like any other interface's driver ... and not have
interfaces accessible otherwise? No auto-claim.
Trivial if sysfs binding info becomes writable (the
symlink syscall could do that), vs. just readonly.
* How should devices be presented? My initial guess is
as a directory, with subdirectories for each interface
and one file for ep0 access. (Unconfigured devices
will have no interfaces, so no per-interface ep0 file.)
Plus of course the sysfs info.
* How should buses be presented? Maybe not at all, other
than by the root hub having a different type of name.
* How will USB OTG support affect this? Hard to say just now,
but it'll be good to keep that in mind.
Anyway, that's a bunch of random thoughts and questions in the
direction of "usbfs2". I hope they can help seed discussions!
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
