On Sun Jul 19 07:53:33 EDT 2009, 9f...@hamnavoe.com wrote: > > I think it's better to remove the timeout from bulk endpoints (perhaps by > > making it optional) > > There's already a general way to time out any read/write operation > alarm() and notify(). Why add a special case option for one particular > type of file? I would say just remove it.
i'm confliced on this one. i want to agree with you, but have recient memory of uncooperative devices. and i would hate to limit the functionality of usb because we're trying to make things too simple. i'm not up-to-speed on usb. aren't there device types that take timeouts in their requests? isn't it easier to set up time timeout at the beginning? are there devices that if given a timeout will give their best available data when the timeout expires? sd doesn't deal with this problem. for example, currently most of the sd devices (orion is an exception) are uninterruptable. and you get whatever timeout you get. the sticky bit is that scsi and ata devices implement timeouts on the devices. these might not always be appropriate and you can't depend on anything. i have drives that vary from 53000s default timeouts to 2s default r/w timeouts. if you need a longer timeout than the disk or driver wants, you can't specify that with an alarm(2). and if you want a shorter one, aborting commands can take several seconds with sata devices. - erik
