"Justin T. Gibbs" <gibbs@freefall.freebsd.org> writes:

> 
> > > > The plan was to basically restructure the SCSI system so that you only
> > > > sleep in one place.  So, a process might sleep at the time it queued an I
> >/O
> > > > request waiting for its scsi_xfer struct to be allocated/reserved, but th
> >at
> > > > once it got that structure, the controller resources would already be
> > > > attached to it and no further sleeping would be needed.  This also ensure
> >s
> > > > that all mallocing is done outside of an interrupt context.
> [...]> 
> I think Julian will remeber things a little differently.  We had been
> discussing SCSI issues throughout the day and removing SCSI_NOSLEEP
> was one of the issues we discussed.  I know that Julian talked to 
> Charles about SCSI issues too before dinner, so perhaps Charles was
> the first to bring up the SCSI_NOSLEEP issue, but he wasn't the one
> to propose a solution for it.

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

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).