>Not true.  I am definitely the person who suggested reserving data
>structures via a call down from the strategy routine.

We'll just have to disagree then.

>However, I'm beginning to question the theory that it's okay to sleep
>from a strategy routine; while it doesn't currently *break* anything,
>per se:
>
>1) it's something that's never been done in BSD (and as far as I know
>has never been done in BSD/OS),
>
>2) it's not clear that it's unreasonable to call a strategy routine
>from an interrupt context (and this is currently the only thing
>preventing it), and
>
>3) I question highly some of the consequences of it (most notably that
>a process waiting for a buffer may end up sleeping due to resource
>deprivation on the device and/or controller of a delayed write buffer,
>possibly much longer than it would otherwise have to wait if it gets
>unlucky).

I agree with all of these points, and provide what I think is a
solution.  The main problem here is that the buffer is pulled off
the queue only based on a per device openings number.  For the
aic7xxx driver, the number of openings is arbitrary and based on
the number of tags we feel like allowing a device to consume.  This
just isn't enough information to ensure that all the resources we
need are availible.  Instead, the SCSI system should track the
number of controller openings and device openings and only proceed
if both are availible.  The SCSI system could also monitor the
number of openings allowed on a per device level and modulate them
based on rtprio or for fairness in sharing controller openings
among competing devices.  With this strategy, you should never
have to sleep and you don't need a software queue in each driver
(as Jason proposed).

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