Anyway, maybe my understanding is too much from the textbook :)  Maybe we'd 
better define the blockong behaviour more flexiable according to the actual 
application senario. 
Correct me if any, thanks.
----------------------------------------
> From: unicorn_w...@outlook.com
> To: oneu...@suse.de
> CC: linux-usb@vger.kernel.org
> Subject: RE: question on skel_read func of usb_skeleton.c‏
> Date: Fri, 12 Jul 2013 13:09:23 +0000
>
> Oliver, my understanding is the limit_sem will only cause write() to sleep 
> and wait for other IOs to finish when there are alreay WRITES_IN_FLIGHT URBs 
> are on going. I see code line 509: sema_init(&dev->limit_sem, 
> WRITES_IN_FLIGHT);
> My understanding of Blocking IO should block every write() when corresponding 
> URBs is not finished, am I right?
>
> ----------------------------------------
>> From: oneu...@suse.de
>> To: unicorn_w...@outlook.com
>> CC: linux-usb@vger.kernel.org
>> Subject: Re: question on skel_read func of usb_skeleton.c‏
>> Date: Fri, 12 Jul 2013 10:30:28 +0200
>>
>> On Friday 12 July 2013 04:49:54 WangChen wrote:
>>> Hi, Oliver,
>>> Regarding skel_write, I see your current desgin only refuse its execution 
>>> when> WRITES_IN_FLIGHT are on the fly, but this is not blocking IO due to 
>>> write() will not wait before callback returns, right? Do you think it's 
>>> unnecessary to support blocking IO on write or any special reason else?
>>
>>
>> /*
>> * limit the number of URBs in flight to stop a user from using up all
>> * RAM
>> */
>> if (!(file->f_flags & O_NONBLOCK)) {
>> if (down_interruptible(&dev->limit_sem)) {
>>
>> The limit_sem will cause write() to wait for IO to finish,
>> if the limit is reached
>>
>> retval = -ERESTARTSYS;
>> goto exit;
>> }
>> } else {
>> if (down_trylock(&dev->limit_sem)) {
>> retval = -EAGAIN;
>>
>> Unless non-blocking IO is used. In that case we return.
>>
>> goto exit;
>> }
>> }
>>
>> Blocking IO is perfectly well supported. To keep under the limit you don't
>> have to wait for the IO you started. Any IO will serve the purpose.
>>
>> Regards
>> Oliver
>>                                        

Reply via email to