From: Oliver Neukum <oliver@neukum.org>
To: Duncan Sands <baldrick@free.fr>
Subject: Re: MAX_USBFS_BUFFER_SIZE
Date: Fri, 3 Mar 2006 11:34:10 +0100
User-Agent: KMail/1.8
Cc: =?iso-8859-1?q?Ren=E9_Rebe?= <rene@exactcode.de>, Greg KH <greg@kroah.com>,
       linux-kernel@vger.kernel.org
References: <200603012116.25869.rene@exactcode.de> <200603012242.35633.rene@exactcode.de> <200603012259.26790.baldrick@free.fr>
In-Reply-To: <200603012259.26790.baldrick@free.fr>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200603031134.10638.oliver@neukum.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 894
Lines: 20

Am Mittwoch, 1. M?rz 2006 22:59 schrieb Duncan Sands:
> > So, queing alot URBs is the recommended way to sustain the bus? Allowing
> > way bigger buffers will not be realistic?
> 
> usbfs could copy the user buffer to a bunch of non-contiguous pages, and
> then fire those off in an urb using the scatter-gather stuff.  [Rather than,
> as now, allocating a bunch of contiguous pages using kmalloc].  That would
> probably make it possible to use much much bigger user-space buffers.  Plus
> the code looks rather easy to write.

It seems to me that that would change the API. The scatter/gather stuff
can fail partially, can't it?

	Regards
		Oliver
-
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/