On Tue, Jun 15, 2004, David Brownell <[EMAIL PROTECTED]> wrote:
> 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.
Backward compatibility could exist simply by keeping usbfs1 around for a
little while, but keeping it deprecated.
I'd rather start from scratch to avoid some of the mistakes that usbfs1
made.
> 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.)
I don't care much about file-per-endpoint and I suspect most other
people wouldn't care much either. It doesn't buy us much.
AIO is definately something I would like to see.
> 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.)
I agree. While libusb works with C and C++, other programming languages
should be able to use usbfs2 as well.
> * 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.
If sysfs works well, I don't see any requirement for usbfs2 to duplicate
that feature.
Especially since sysfs works for all devices.
> * 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.
Perhaps a sockets interface would be more appropriate?
Device nodes work well for a generic API like block or character
devices, but it gets into problems with USB.
> * 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.
I can't think of any reason why we need to have non-current
configurations (or alternate settings) exposed through sysfs or usbfs2.
In fact, exposing it could be confusing.
> * 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.
I agree with you.
> * 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.
usbfs1 works like that right now, except for it autobinds (with some
comments in the code to remove that "feature")
> * 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.
Ideally I'd like to see a single directory with all of the endpoints and
symlinks from interface directories to the endpoint directories.
> * 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!
To be honest usbfs1 hasn't limited the functionality in libusb too much.
I would just like to see cleaner interfaces in some areas. Specifically
asynchronous transfers and device connect/removal.
I guess the latter could be solved by some tighter integration into udev
as well.
JE
-------------------------------------------------------
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
