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

Reply via email to