[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-scsi
Subject:    Re: HEADS UP: scsi changes in 2.5.1-pre
From:       Jens Axboe <axboe () suse ! de>
Date:       2001-11-30 19:27:00
[Download RAW message or body]

On Fri, Nov 30 2001, Stephen Cameron wrote:
> Jens Axboe (axboe@suse.de) wrote:
> 
> > On Thu, Nov 29 2001, Christoph Hellwig wrote:
> > > I'd like to note to the driver maintainers that 
> [...]
> > > for scsi drivers this means that io_request_lock is gone and is replaced by
> > > queue->queue_lock.  
> [...]
> > Addition to the above -- the io_request_lock is gone, but it has been
> > replaced by _two_ other locks. Basic queue protection is done with
> > q->queue_lock as Christoph mentions, however low level drivers are
> > generally protected with host->host_lock now.
> 
> Could someone elaborate on when a low-level driver should use the
> host_lock vs. when it should use the queue_lock for those of us who
> are a bit slow on the uptake?  Before seeing this thread, I got the 
> impression I could just replace io_request_lock with host_lock in 
> the low level driver...now I'm not sure. (Not that I was really ever
> very sure...)

Ok, you probably _never_ want to use the q->queue_lock. It just protects
the block level queue and associated structures. You can pretty much
assume (at least currently) that low level driver strategies that were
previously entered with io_request_lock held are now entered with
host->host_lock held instead. The exception is detect() afair (did this
long ago :-), which holds no locks.

-- 
Jens Axboe

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

[prev in list] [next in list] [prev in thread] [next in thread]