On Wed, 8 Feb 2006, Greg KH wrote: > > Given an existing driver for an existing device (FWIW, pretty special > > device, nothing consumer-like, think of several 10k$ value) which: > > Which is no different than any other device we support. No one is > "special" here, we have drivers that I know only have 2 devices out > there in the wild. Hell, we have a whole sub-arch for only 2 machines > :)
Sure. Just wanted to explain nobody is ever missing the driver source in this case because customers buy some rather big machine with SLA and whatever. But we do perfectly agree, there's no point treating this special in any respect. So my question does also include consumer-like devices ;-) > > * lives in kernel space using the current EXPORT_SYMBOL api > > * is not derived from any GPL code thus not "GPL-infected" > > * is not open source due to the copyright holder's free decision > > Have you consulted your lawyers about this? I have consulted mine, and > they say that it is illegal to have a Linux kernel driver that is not > open source. Well, different lawyers apparently say different things - so maybe it's up to the court to decide at some point. Maybe this indicates an unenforceable weakness of the GPL because there's too much left to debate what "derived" really means. But that's not what I'm trying to understand here. > > * 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. > > * 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. 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. > > 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. > > 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. 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. > > I'm sure this was thoroughly discussed somewhere, but I probably > > missed that. Where can I find a pointer to the discussion of this > > decision? > > It's right here, right now :) Glad, I'm not too late to speak up then ;-) > > 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. Would need to evaluate despite of having a working driver :-( 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. 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. 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? It's a matter of trust in the future of non-technical development of the platform as well. So, if my understanding was correct and the intention is not to have an api like EXPORT_SYMBOL useable for all kind of legitimate drivers (including non-gpl) I really need to collect all facts and re-evaluate the pro's and con's. Is there some up-to-date specification of the usbfs-api available somewhere? Thanks, Martin ------------------------------------------------------- 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
