usbfs and MAX_USBFS_BUFFER_SIZE

[Daniel Drake]

Hi,

Can someone explain the purpose of MAX_USBFS_BUFFER_SIZE?
It is defined in drivers/usb/core/devio.c:

#define MAX_USBFS_BUFFER_SIZE 16384

It is checked in proc_do_submiturb() (i.e. async urb submissions) for
control, bulk, and interrupt transfers.

If you want to do a bulk transfer of larger size, no problem: split your
request into a few smaller URBs and everything will work.

If you want to do an interrupt transfer of larger size, no problem: same
solution as bulk

But the real problem:

If you want to do a control transfer of larger size, you're out of luck!
You can't divide up control messages like that, since the setup packet
header for each URB is interpreted by the device.

It looks like the only way to submit control URBs larger than 16kb using
usbfs is to use the synchronous USBDEVFS_CONTROL ioctl -- there is no
async way.

Any comments/thoughts on that?

Thanks,
Daniel

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Pete Zaitcev]

Post by Daniel Drake
Can someone explain the purpose of MAX_USBFS_BUFFER_SIZE?
#define MAX_USBFS_BUFFER_SIZE 16384

It's there to prevent random failures because of memory fragmentation,
by turning them into reliable failures.

Post by Daniel Drake
If you want to do a control transfer of larger size, you're out of luck!
You can't divide up control messages like that, since the setup packet
header for each URB is interpreted by the device.
It looks like the only way to submit control URBs larger than 16kb using
usbfs is to use the synchronous USBDEVFS_CONTROL ioctl -- there is no
async way.

The control should be limited to a page. It is preposterous to think
of anyone trying to send a control message with a buffer bigger than
a couple hundred bytes, a thousand at most. If you managed to trick
USBDEVFS_CONTROL into sending more than 16KB at a go, a check must be
missing somewhere.

-- Pete

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Daniel Drake]

Post by Pete Zaitcev
The control should be limited to a page. It is preposterous to think
of anyone trying to send a control message with a buffer bigger than
a couple hundred bytes, a thousand at most. If you managed to trick
USBDEVFS_CONTROL into sending more than 16KB at a go, a check must be
missing somewhere.

Fair argument. I haven't actually tried sending a big urb through
USBDEVFS_CONTROL but I noticed that MAX_USBFS_BUFFER_SIZE is not checked
in that codepath. I wonder if something else in the chain will reject
big control urbs.

Daniel

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Alan Stern]

Post by Daniel Drake

Post by Pete Zaitcev
The control should be limited to a page. It is preposterous to think
of anyone trying to send a control message with a buffer bigger than
a couple hundred bytes, a thousand at most. If you managed to trick
USBDEVFS_CONTROL into sending more than 16KB at a go, a check must be
missing somewhere.

Fair argument. I haven't actually tried sending a big urb through
USBDEVFS_CONTROL but I noticed that MAX_USBFS_BUFFER_SIZE is not checked
in that codepath. I wonder if something else in the chain will reject
big control urbs.

There's this in proc_control():

if (ctrl.wLength > PAGE_SIZE)
return -EINVAL;

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[David Brownell]

Post by Daniel Drake
I wonder if something else in the chain will reject
big control urbs.

The HCDs have limits. ISTR that OHCI and EHCI pick
something convenient; 4 KBytes is save, more is iffy.


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Pete Zaitcev]

Post by Daniel Drake
Fair argument. I haven't actually tried sending a big urb through
USBDEVFS_CONTROL but I noticed that MAX_USBFS_BUFFER_SIZE is not checked
in that codepath. I wonder if something else in the chain will reject
big control urbs.

But you did want it for something, didn't you? Or just idle curiosity?
If you're writing microcode, please avoid using control transfers for
uploading firmware without breaking it up explicitly.

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Daniel Drake]

Post by Pete Zaitcev

Post by Daniel Drake
Fair argument. I haven't actually tried sending a big urb through
USBDEVFS_CONTROL but I noticed that MAX_USBFS_BUFFER_SIZE is not checked
in that codepath. I wonder if something else in the chain will reject
big control urbs.

But you did want it for something, didn't you?

Not exactly. I am writing a userspace USB I/O library (like libusb), and
during testing I realised that I could not submit a bulk URB for ~110kb
of data. While implementing the code to divide the request into several
URBs, the thought "I wonder how this works for control URBs" crossed my
mind. That's all :)

I published the source of my library yesterday:
http://www.reactivated.net/fprint/wiki/Fpusb

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sarah Sharp]

Hi Daniel,

Have you looked at usbfs2? It sounds like usbfs2 and fpusb have some similar
goals, although I admit I only glanced briefly at your wiki.

http://wiki.cs.pdx.edu/usb/usbfs2.html

Sarah Sharp

Post by Daniel Drake

Post by Pete Zaitcev

Post by Daniel Drake
Fair argument. I haven't actually tried sending a big urb through
USBDEVFS_CONTROL but I noticed that MAX_USBFS_BUFFER_SIZE is not checked
in that codepath. I wonder if something else in the chain will reject
big control urbs.

But you did want it for something, didn't you?

Not exactly. I am writing a userspace USB I/O library (like libusb), and
during testing I realised that I could not submit a bulk URB for ~110kb
of data. While implementing the code to divide the request into several
URBs, the thought "I wonder how this works for control URBs" crossed my
mind. That's all :)
http://www.reactivated.net/fprint/wiki/Fpusb
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Daniel Drake]

Post by Sarah Sharp
Hi Daniel,
Have you looked at usbfs2? It sounds like usbfs2 and fpusb have some similar
goals, although I admit I only glanced briefly at your wiki.
http://wiki.cs.pdx.edu/usb/usbfs2.html

We already spoke briefly in private email. I haven't looked at the code yet.

I may be wrong, but I feel that a userspace library to access usbfs2
will still be useful, to simplify certain concepts and reduce duplication.

Also, I'm hoping that my library will provide portability to other O/S's
in the future, like has been done with libusb. It will also act as a way
of hiding the differences between usbfs and usbfs2 from the application
developer, by providing the same API to do the same thing over both.

One of my personal goals is to provide a fd-oriented async interface to
applications, so that those applications can learn when the library has
something to do (i.e. iteration function needs to be called) by polling
some file descriptors. This is possible with usbfs as you can select()
on the existing nodes for URB completion. I'm not sure how this fits
into the usbfs2 scheme of things as I haven't yet read up on the AIO
stuff you pointed me to.

I do like the design goals of usbfs2 and do plan to use it within fpusb
when it comes available - and presumably it is possible to get pollable
file descriptors which describe AIO completion.

Thanks,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Daniel Drake]

Post by Sarah Sharp
Hi Daniel,
Have you looked at usbfs2? It sounds like usbfs2 and fpusb have some similar
goals, although I admit I only glanced briefly at your wiki.

Reading your email again, I should probably clarify:

fpusb is a userspace library which provides a C API to access usbfs.

It's not a replacement for usbfs/usbfs2, which is what I presume you
thought when you saw the webpage.

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sarah Bailey]

Post by Daniel Drake

Post by Sarah Sharp
Hi Daniel,
Have you looked at usbfs2? It sounds like usbfs2 and fpusb have some similar
goals, although I admit I only glanced briefly at your wiki.

fpusb is a userspace library which provides a C API to access usbfs.
It's not a replacement for usbfs/usbfs2, which is what I presume you
thought when you saw the webpage.

Ah, yes, that clarifies things. Thanks.

Sarah

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel