>
>"Justin T. Gibbs" <gibbs@freefall.freebsd.org> writes:
>
>> 
>> >Additionally, the behaviour suggested in item 2 would require either
>> >disallowing the start routine from ever sleeping (meaning that it
>> >would always have to use SCSI_NOSLEEP), or adding an additional lock
>> >to prevent another process entering the start routine (from the
>> >strategy routine) and trying to start the same buffer.
>> 
>> Hmmm, yuck.  You could work around this by guarding against the
>> queue being empty.  The only real restraint here is that the
>> transactions are queued in the same order as the buffers (tape writes
>> won't work otherwise), but you don't care if the buffer you pull off
>> the queue is the same one that you looked at before you slept.
>
>In the case where the adapter driver or mid-level code sleeps waiting
>for memory, that's not applicable, because you're still operating on
>the same buffer when you wake up.  In this case, since you haven't yet
>dequeued the buffer (per Noriyuki's suggestion), there is a race
>condition.  Since you never sleep directly from *start(), but only
>from some lower-level code, I'm not sure what it is you're talking
>about.

I was assuming that *start() would call getxs before even touching
the buffer queue so that no association between scsi_xfer struct
and buffer is made until all resources are reserved.  This is again
with getxs calling down into the controller driver to reserve its
resources before returning and scsi_scsi_command taking a scsi_xfer
struct as an argument instead of attempting to get one itself.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================