lkml.org 
[lkml]   [2005]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH] incrase usbdevfs bulk buffer size
On Sun, Oct 02, 2005 at 09:10:14PM -0700, Pete Zaitcev wrote:
> On Sun, 2 Oct 2005 15:34:22 -0400, Christopher Li <usb-devel@chrisli.org> wrote:
> >
> > I think the API is kind of fine in this aspect. The usbdevfs should be
> > able to take bigger than 16K, but the internal copy of the urb does not
> > have to use kmalloc on data buffers.
>
> You miss an important detail here, namely that single URBs do not have
> a capability to transfer to a discotiguous buffer. As long as you try

That is exactly my point that the kernel should not limit itself on only
using contiguous buffers. Every USB controller can handle discrete DMA
buffer why shouldn't the kernel? Obviously it should be nice to address
the contiguous buffer restriction before bump up the bulk transfer limit.

> to map one transfer insive VMware to one URB, one and only one kmalloc

The current usbdevfs does a extra copy between from the user space urb
to the kernel space urb. So it does not matter if the user space urb is
contiguous or not. If the kernel can handle discrete dma internally,
the usbdevfs could use it and maintain it's current API.

BTW, That is not VMware choice how the data buffer was arranged. It is the guest.

> has to be done. But if splitting the transfer is acceptable, there is

I still think fixing the kernel to allow address scatter-getter buffer and
allow bigger buffer size is the right thing to do.

Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-03 08:39    [W:0.049 / U:1.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site