On Wed, Feb 08, 2006 at 11:54:15PM +0100, Martin Diehl wrote: > On Wed, 8 Feb 2006, Greg KH wrote: > > > > * implements several usb configurations and interfaces which have certain > > > requirements ruling out a userspace driver in the past and future > > > > What do you mean by this? Specifics please. > > Driver needs to deal with several configurations with multiple interfaces > each. Custom-designed protocol. Both bulk and iso endpoints with latency > requirements. Not hard realtime, but response time is critical which > became tricky when sharing locks f.e.
Response time to incomming packets (to turn around and send something else out?), or response time for something else (queuing, etc.)? > > > * was validated and approved by the FDA so any change is very expensive > > > * is almost impossible to migrate to usbfs due to FDA regulatory affairs > > > because libusb or whatever would become part of the critical path - > > > even if it were technically possible > > > > Then stick with an older kernel version, I'm sure you can't just > > re-evaluate every new kernel release too. Just like there is Linux 2.0 > > in some machines, no one is forcing you to upgrade to 2.6.34 or greater > > :) > > Yes, there's no need to upgrade with any kernel release. However, the > supported lifetime of the device might be 10 years. I'm not going to cheat > my customers telling them their investment in Linux would be safe because > it's open source and updates will always be available if I already knew, > that's not the whole truth. It's not the truth if you have a closed source driver, and if so, you would be cheating them that way :( > Sure, they can always hire somebody to maintain 2.4 for the next 10 > years. But I know what happens next, so this is not an option to > suggest. Again, not a fair argument, based on your closed source driver :) > > > I'm looking for some statement how the USB-api will provide the backward > > > compatibility. > > > > What "backward compatibility"? Since when is the in-kernel api > > guaranteed to be backward compatible 2 years from now, let alone 2 days > > from now? > > Dont't get me wrong, I'm neither complaining nor asking for guarantees. > Sure, the driver might need some maintenance when switching kernel release > once every two or three years. Living with an api as a moving target is > one thing, beeing locked out something different. I'm just trying to > anticipate what will become fact-of-life in the foreseeable future. The only reason you are being "locked out" is due to your license, which is your own doing. Recall that almost every kernel developer hates closed source modules, as you are merely "taking" from Linux, and not abiding by our license (for a specific example, usb.h is under the GPL, you can not use that to build your driver, how do you get around that?) > > > If I understand this patch correctly, the intention is to declare the > > > usb-driver-api non-existing in two years from now. > > > > No, it's not "non-existing", it's just going to be even that much harder > > for non-gpl code to use it. All of the in-kernel drivers will continue > > to work just fine. > > If it exists, I don't see the point of EXPORT_SYMBOL_GPL in the first > place. Any GPLed patch may remove the _GPL and that's it. See Linus's point about this in the lkml archives. I'm not going to argue it here. If you want to do this, fine, do it and then don't worry about this issue (but you will have other issues to worry about...) > I don't see how anybody could have GPL'ed code restricting its api > from being legitimately called by non-GPL code (no derived work) > without violating section 6 of the GPL by itself. So if the intention > is to keep non-gpl callers away, I think the only way is to declare > the api gone - whatever this means. No, it signifies "intent". Again, see the lkml archives for details. But hey, I'm not going to argue license issues here, as I'm not a lawyer, and I never want to play one on TV. Let's discuss the technical reasons why usbfs does not work for you, and what we can do about that. > > > Is there any other suggestion then either creating an individual (GPL) > > > api for such a driver or switching to an OS with sane api? > > > > How about we talk about the specifics of why you can not use > > libusb/usbfs today? What is lacking that keeps you from doing this? > > And have you considered a tiny shim driver, like ldusb is, to handle the > > issue where libusb/usbfs does not work well? Is there anything that you > > would like to see enhanced in order to work properly for your systems? > > Maybe something has changed since I've checked last. Maybe libusb/usbfs > might be ready to fulfill the requirements now or after some future > additions. Great. > Would need to evaluate despite of having a working driver :-( Well, you have 2 years to do so :) > Unfortunately this is only part of the problem. Even then we still have > those guys in the critical path. And since no in-kernel driver depends on > features or code paths I need for the device, any kind of surprise might > happen there. No, we do not break userspace interfaces like that, and will not in the future. That is your guarantee, userspace APIs will stay there. That's why I can run a binary that was built on 0.98 just fine on 2.6 today. > Of course, as the maintainer you have to keep in mind all the drivers > so I fully understand you cannot always care for what I'd like to get > changed once something gets broken for me only. In the end chances are > I would have to maintain some fork. If you use usbfs, you should not have to maintain such a fork. If you point out problems that happen, and if we break such an api, we will gladly fix it. Note, lots of people us usbfs just fine, like vmware for example, who emulates all of the Windows stuff on top of it. So it is pretty stable. > Doable of course - but if I have to rewrite the driver for libusb and > need to maintain my own usbfs/libusb/ldusb - why not just porting the > driver to BSD and be done? If you use libusb, it will work just fine on all BSDs too, as libusb works there too. I've heard it even works on Windows if you want to go that route too. So maybe this is a better option for you. > Is there some up-to-date specification of the usbfs-api available > somewhere? include/linux/usbdevice_fs.h is about all that we have. But libusb has some good documentation, and there are lots of applications out there that use usbfs that you can look at for examples (gphoto2, usbutils, etc.) Unfortunatly, most of the applications that really streach usbfs to its limits, and get full bus speeds, are all closed source, so looking at them for examples will not be possible. hope this helps, greg k-h ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
