[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87eg92p3cn.fsf@linux.intel.com>
Date: Mon, 16 May 2016 15:57:44 +0300
From: Felipe Balbi <felipe.balbi@...ux.intel.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: "Du\, Changbin" <changbin.du@...el.com>,
Al Viro <viro@...iv.linux.org.uk>,
"gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
"mina86\@mina86.com" <mina86@...a86.com>,
"rui.silva\@linaro.org" <rui.silva@...aro.org>,
"k.opasiak\@samsung.com" <k.opasiak@...sung.com>,
"lars\@metafoo.de" <lars@...afoo.de>,
"linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: gadget: f_fs: report error if excess data received
Hi,
Alan Stern <stern@...land.harvard.edu> writes:
> On Fri, 13 May 2016, Felipe Balbi wrote:
>
>> We deliver to userspace the part userspace requested, right? So that's
>> okay. The USB details WRT e.g. babble or host trying to send more data
>> than expected, needs to be handled within the kernel.
>
> The point is that you don't know whether the host sent more data than
> expected. All you know is that the host sent more data than the user
> asked the kernel for -- but maybe the user didn't ask for all the data
> that he expected. Maybe the user wanted to retrieve the full set of
> data using two read() system calls.
right, but that just means we need to buffer the data instead of bailing
out of the first read() completely.
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)
Powered by blists - more mailing lists