On Wed, 8 Feb 2006, Greg KH wrote: > > 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.)?
Queueing was one issue. Another point f.e. is the device uses the USB SOF-counter as its internal hardware clock. Certain requests to the device need to deal with some timestamp operation (like saying "execute this request at a particular frame-#"). For this to work the driver needs to read the current SOF-counter and submit the urb such that the device will execute it within about 5ms (in most cases - if we were missing this every now and then, no problem). Would this be possible with usbfs - I mean for iso-support the frame counter needs to be accessed anyway? > 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?) Like you, I don't wanted to start a discussion focussing on GPL issues here. So just a few final comments from me before getting back to technical questions. Sure, I know many kernel people feel pretty strong about CS drivers. I do also know many users which would like to use Linux and don't understand why they can't because it seems some people pretend no driver available would be better than a CS one. Yet, GPL is neither about hating or loving someone's personal taste, but about legal permissions and restrictions. So, with all due respect, I'd rather follow the GPL than to work around personal feelings. If this means a non-gpl driver cannot exist in the kernel anymore - fine, I'll have to deal with it. And some final word about "taking from Linux". Sure, using it for the system is taking from it. As you know, personally I'm not abusing this as an one-way-street. I've released drivers under GPL, contributed patches to the kernel and tried to help other people - this was financed from my private money, no sponsor or distributor paying me. Don't get me wrong, of course I do know many people have contributed much more and I also know this wouldn't buy me the right to do things violating the GPL. But that's not the point, I'm not asking for some special admittance nor do I want to violate the GPL. I'm just wondering about making a personal mistake when believing in the "give something back" approach and tried to be fair. But anyway, this would be my personal problem so let's just return to the technical issues. > > 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...) Right. While I personally don't see anything different with or without the trailing _GPL, things get complicated here. So patching it back out is not an option I'm willing to rely on. And I was trusting this wouldn't be necessary given Linus' provision existing EXPORT_SYMBOL would remain. Seems history proved me wrong. > > 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. But even if it became technically possible, the two other points remain: Why investing the major effort of rewriting and validating an existing working legitimate driver just because people decide to express their intent that way, as you explained? And, what is the price of depending on usbfs in the critical path? > > Would need to evaluate despite of having a working driver :-( > > Well, you have 2 years to do so :) Right. As I said, this should be sufficient to consider any option. > > 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. It's more about depending on code paths in usbfs which are not covered by other users. > > 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. It's much too early for me to tell whether it makes sence to rely on usbfs or better use a fork or replacement. > > 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. cross-platform isn't an issue here. What I'm looking for - besides other things of course - would be a platform where I can trust on rather stable api on the longer timescale. Having to update the driver every few years isn't a big deal - in contrast to driver rewrite just because people express their intention. Taken this way I really appreciate your patch as it makes clear the direction Linux is probably going in the future so everybody can make up his mind. > > 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, Yes, thanks. I need to think about the usbfs thing now. If it suffices, I might come back later with further questions or patches :) 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
