Hi,
On 06/06/2012 04:40 PM, Sarah Sharp wrote:
On Wed, Jun 06, 2012 at 10:10:04AM +0200, Hans de Goede wrote:
<snip>
3) Akin to 2). We also need some way to pass iovecs, rather then
a regular buffer for urbs. I suggest making yet another struct usbdevfs_urb
change for this, replacing:
void *buffer;
int buffer_length;
With:
union {
void *buffer;
struct iovec *buffer_iov;
};
int buffer_length; /* buffer length in bytes, or number of buffer_iov elements */
In the iovec case, buffer_length should be zero (transfer the whole
iovec) or non-zero (transfer part of the iovec), correct?
No it would indicate the number of elements in the iovec array, the call will always try
to transfer the whole iovec, just like with writev / readv.
And adding a flag userspace can use to indicate if the buffer is an iovec rather then
a regular buffer.
Where would the flag be added? Or would it just be another ioctl
number?
In the existing flags field :)
4) Userspace needs to know if it can use bulk streams and / or iovecs, and it would be
good to have a better test then checking the kernel version, esp. as we expect some of
this to get backported to older kernels. Therefor I suggest adding a USBDEVFS_GET_CAP
ioctl which takes an u64 * as arg and stores a capabilities bitmask there. This bitmask
will reflect if the kernel knows about bulkstreams for example, not if the device the
ioctl is happening on happens to support bulkstreams.
Sure, makes sense.
Thats all for now. One last remark: We must not forget to document that the
URB_SHORT_NOT_OK flag does not always halt the ep on a short urb!
Yes! Or maybe usbfs should simply return with an error any URBs that
have the BULK_CONTINUATION flag set when it's submitted to a host
controller with a non-zero sg_table length.
You will also need a new ioctl to allow userspace to allocate a specific
number of bulk streams for a set of endpoints under an interface. usbfs
should check that the driver has claimed the interface before calling
into usb_alloc_streams(). Similarly, there needs to be an ioctl to
deallocate streams, which needs to call usb_free_streams().
Right, I considered the need for those 2 obvious and the design of them
not really interesting, which is why I did not mention them.
Perhaps if a driver unclaims an interface, usbfs should automatically
attempt to deallocate streams.
Right, and it must definitely deallocate them if the usbdevfs handle gets
closed!
That probably means usbfs needs to keep
track of which endpoints have streams.
It needs to do that anyways to decide whether it should honor the
stream_id, since old apps may use uninitialized memory for this part
of the struct when doing bulk transfers.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
