Re: [PATCH] NCR53C9x ESP: C99 designated initializers

Linus Torvalds (torvalds@transmeta.com)
Mon, 11 Nov 2002 13:01:00 -0800 (PST)


On Mon, 11 Nov 2002, Doug Ledford wrote:
>
> Yes, this part sucks. There needs to be an easy library function that
> takes a scsi command pointer, sets up a wait queue, adds the wait queue
> struct pointer to the scsi command, sleeps with a timeout, wakes up when
> command completes via scsi_done() or timeout fires, returns value based
> upon how wake up happened.

I think you got it wrong.

The timer should be started when the command is started, not when it is
queued.

Just adding the command to the request queue and doing a wait-queue'd
"schedule_timeout()" is bad, because a previous (and unrelated command)
may be taking a long time, and may be delaying the new command which works
perfectly fine and returns immediately.

Example: somebody does a "close tray and read". Where it should be
perfectly possible to give the read command a short timeout, even if the
close tray takes a few seconds.

And btw, this has nothing to do with SCSI per se, so adding the thing to
the scsi command struct is bad, evil, and the reason for why the SCSI
mid-layers will eventually have to go away (ie they do exactly this kind
of thing, and _encourage_ people to do them).

We've got almost all of the infrastructure to do this on a request level
now, including the timeout value (but nothing that sets the timeouts for
regular IO).

We don't have the starting of the timer thing there, and that's at least
partly because I really think the timer should be started and set up by
the driver itself - and that's because only the driver can know if it can
actually remove the request and how to do it.

If the request ends up being pending and holding up other requests
(because the driver doesn't know how to physically abort it), we MUST NOT
return it as being "aborted due to timeout", because higher layers cannot
de-allocate the request anyway (imagine the thing later on waking up and
scribbling on memory that has now been free'd because the command "timed
out").

But yes, we want the infrastructure for doing this easily some day. As it
is, that's 2.7.x material by now.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/