On Wed, Feb 08, 2006 at 09:26:07PM +0100, Martin Diehl wrote: > On Wed, 8 Feb 2006, Greg KH wrote: > > > Currently we don't have a way to show people that some kernel symbols > > will be changed in the future from EXPORT_SYMBOL() to > > EXPORT_SYMBOL_GPL(). As we all know, not everyone reads the > > Documentation/feature_removal.txt file, so we need a bigger way to > > remind people. > > Ok, two years from now isn't much but might be sufficient time left to > switch to a different OS if needed. So we need to make a decision now. > Following the usb-part of the patch wrt. feature-removal-schedule I'd like > to ask here as follows: > > 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 :) > * 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. > * 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. > * 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 :) > 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? > 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. > 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 :) > 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? thanks, 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
