On Thursday 09 February 2006 12:32 am, Martin Diehl wrote: > 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.
In what sense? You _can_ queue through usbfs, though I'd rather just see the normal AIO calls work there ... lower overhead, simpler, etc. > 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? This is the first driver I've heard of that tries to do that sort of synchronization using the frame counter. Doesn't look to me as if that's accessible from userspace just now ... and I know for a fact that virtually none of the ISO schedulers implement policies other than "next available slot". (So, "now plus N frames" won't happen using either kernel or userspace driver APIs.) > > > 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. Time enough to for example come up with a "usbfs2" to support closed source drivers from userspace, using better and more maintainable models than today's "usbfs"... > It's more about depending on code paths in usbfs which are not covered by > other users. That's IMO a valid concern. I would not say that for example usbfs was designed for testability, and it certainly doesn't interoperate well with any of the standard I/O stream APIs. (Surely you _ought_ to be able to pass a file desriptor USB-unaware programs, like "cat" and so on...) > > > Is there some up-to-date specification of the usbfs-api available > > > somewhere? There's a chapter in the usb kerneldoc (Documentation/DocBook/usb.pdf) that gives an overview and describes most of the ioctls. I'd not say it's especially up-to-date, but on the other hand usbfs hasn't changed very much so the big picture will still be accurate. - Dave ------------------------------------------------------- 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
