Re: [linux-usb-devel] usbfs2 ... what should be in it?
Hi Johannes, I'd rather start from scratch to avoid some of the mistakes that usbfs1 made. could you say more about these mistakes please. * 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. Reading and writing files should be OK for any language (including scripts). However reading or writing special structures (structs) could be a problem, since imitating C types (getting the size right) and C record layout (padding etc) could be a pain from another language. Can it be done at all from a shell script? (This is one of the bad things about reading device descriptors from the current usbfs files by the way). So sticking to simple things like: echo 1 bAlternateSetting cat my_firmware_file endpoint_file would be nice. * 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. Why is that? * 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. Is this to avoid having to go down the directory tree to get to an endpoint? Ciao, Duncan. --- 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
Re: [linux-usb-devel] usbfs2 ... what should be in it?
Hi Dave, * 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 guess libusb could get a new implementation (wrapper) that maps its methods onto operations on usbfs2 and sysfs. That would maintain backwards compatibility. On the other hand, I guess usbfs won't be going away any time soon, so it's not a big deal. * 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. Yes, sysfs. * 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. I thought of using regular character devices - and while it doesn't feel as elegant as using a special file system, it does have the advantage of being a simple mechanism that everyone understands. * 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.) sysfs should be used for control - selecting configurations, and binding of drivers to devices. * 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. And there's also the problem of race conditions. Imagine that you select a new configuration via sysfs (which maybe triggers the creation of endpoint files for that configuration), and then open an endpoint file. What's to stop someone else changing the configuration between you setting it and opening the endpoint? Also, should it be possible to lock-down a configuration so no-one else can change it? Maybe all configurations should be exposed simultaneously (or at least all endpoints files should always be visible). Then you can grab the endpoint-in-a-certain-configuration file without any problems. But then you have the problem of endpoints in different configurations being manipulated at the same time... I guess the right thing to do is to have only files for the current configuration be visible, but with a naming scheme that makes it impossible to open an endpoint for a different configuration to the one you thought you were opening. * 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. A directory structure: configuration_name/interface_name/endpoint with endpoint being a file. Only the directory for the current configuration would be visible at any given time (of course if you were wandering around inside configuration_name when the configuration was changed, you will still see that directory until you exit due to reference counting). If they're claimed by some kernel driver, or aren't claimed at all, I'm not sure if they should appear. They could appear, but be -EBUSY when you try to open an endpoint. But I think I agree with you here - you should only see interfaces that are available for use. (Other than in sysfs.) We should still have the ability to let usermode code control what kernel driver is bound to which interface. Choosing which driver controls a device goes beyond USB - and should be done somehow via sysfs I suppose. * 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. usbfs2's probe method would need to be called after everyone else's, but that's still an improvement. Of course user-space programs may want exclusive access to an interface, but I guess USB interface claiming shouldn't be used for that - they could obtain exclusivity by
Re: [linux-usb-devel] usbfs2 ... what should be in it?
I forgot about alternate settings, so I guess it should be: configuration_name/interface_name/altsetting_name/endpoint to make sure that endpoints are completely specified by the path. Ciao, Duncan. --- 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
Re: [linux-usb-devel] usbfs2 ... what should be in it?
On Tue, Jun 15, 2004 at 03:29:10PM -0700, Johannes Erdfelt wrote: * 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? From my point of view, a socket interface would definitely resemble USB better. After all, it is a packet oriented bus, and you have different devices with adresses. You also have well-understood semantics of 'binding' to an address, including a failure to bind if the address is already in use. But maybe that's just my strange view on the world as coming from a strong networking background. As already discovered in a recent thread here, USB snooping is very analogous to what tcpdump [or other pcap based software] dpes. The socket level could then determine whether you're intereted in sniffing/sending raw usb packets at the HCD (RAW usb socket) or whether you're interested in communicating with a specific device/interface/endpoint. JE -- - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Programming is like sex: One mistake and you have to support it your lifetime signature.asc Description: Digital signature
Re: [linux-usb-devel] usbfs2 ... what should be in it?
On Wed, Jun 16, 2004, Harald Welte [EMAIL PROTECTED] wrote: On Tue, Jun 15, 2004 at 03:29:10PM -0700, Johannes Erdfelt wrote: * 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? From my point of view, a socket interface would definitely resemble USB better. After all, it is a packet oriented bus, and you have different devices with adresses. You also have well-understood semantics of 'binding' to an address, including a failure to bind if the address is already in use. But maybe that's just my strange view on the world as coming from a strong networking background. As already discovered in a recent thread here, USB snooping is very analogous to what tcpdump [or other pcap based software] dpes. The socket level could then determine whether you're intereted in sniffing/sending raw usb packets at the HCD (RAW usb socket) or whether you're interested in communicating with a specific device/interface/endpoint. I certainly agree there are many similarities. My only concern is with some of the other support that doesn't make sense wrt to sockets. Take for example the reset device call. How would that map into a sockets interface? Maybe we can take the meat of the API and implement by means of a sockets API where it makes sense, and make everything else use an ioctl interface (or something else)? 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
Re: [linux-usb-devel] usbfs2 ... what should be in it?
Johannes Erdfelt wrote: 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. Agree 100%. 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. AIO without file-per-endpoint? Possible, I suppose, with a library layer to demultiplex stuff ... wouldn't it need to take over the per-request private data field? But without file-per-endpoint, read() and write() won't work ... so these file descriptors can't just be handed around to other processes that know nothing about usbfs. I agree. While libusb works with C and C++, other programming languages should be able to use usbfs2 as well. And that works a lot more easily with file-per-endpoint, since those language runtimes probably already include open/close and read/write. The alternative is new glue libraries, likely in C instead of native to that language, to demux things. If sysfs works well, I don't see any requirement for usbfs2 to duplicate that feature. Especially since sysfs works for all devices. Right. Some features belong in sysfs, others don't. * 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? Certainly there are ideas to steal from the network stacks. How do they deal with iso transfers, do you know? Device nodes work well for a generic API like block or character devices, but it gets into problems with USB. What are the problems you're thinking about? Even control transfers can be done with just write/read. 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. Could you elaborate a bit about the connect/remove issues? - 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
[linux-usb-devel] usbfs2 ... what should be in it?
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
Re: [linux-usb-devel] usbfs2 ... what should be in it?
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
