From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <fe321bcc50c2892eb6fa513c8063792f@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 19 Jul 2009 09:40:33 -0400
To: 9fans@9fans.net
In-Reply-To: <1381313165a5f22aeb8498f958cd7513@hamnavoe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] new usb stack and implicit timeouts
Topicbox-Message-UUID: 272e49c4-ead5-11e9-9d60-3106f5b1d025

On Sun Jul 19 07:53:33 EDT 2009, 9fans@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