On Monday 08 July 2013 13:09:05 汪辰 wrote:
> hi,
> I'm reading latest usb_skeleton.c sample and compared with that with ldd3 book.
> Looks like the skel_read changed a lot against previous version. Why we now not use usb_bulk_msg, just due to we want to get chance to cancel the urb if any unexpected exit?
Well, I can quote myself:
USB: skel_read really sucks royally
The read code path of the skeleton driver really sucks
- skel_read works only for devices which always send data
- the timeout comes out of thin air
- it blocks signals for the duration of the timeout
- it disallows nonblocking IO by design
To me the nonblocking IO would already make the old design inacceptable.
> Also in current skel_read function, I am a bit confused by the "retry" logic, why do we need this? Especially, when the var - available would equal to zero and makes the judegment if (!available) true?
The URB may finish at once with an error. Could you elaborate your question?
> Another small quesiton is about :
> /*
> * if we are asked for more than we have,
> * we start IO but don't wait
> */
> if (available < count)
> skel_do_read_io(dev, count - chunk); // <- why don't we judge the return value for this calling?
POSIX says that we either return an error or data. If we are in that
code path, we have data. So there's no use in detecting an error,
if we still can retry.
Regards
Oliver
--
- - -
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
- - -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
