lkml.org 
[lkml]   [2002]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] NCR53C9x ESP: C99 designated initializers

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.020 / U:29.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site