On Sat, Feb 10 2001, Gérard Roudier wrote:
> > You are doing the Right Thing, the io_request_lock will die in the
> > next devel series. And no doubt the hardest part of that is not the
> > actual i/o layers, it's the SCSI low level drivers that do all sorts
> > of funnies with it.
>
> It is not the low level drivers that have invented the offending
> io_request_lock. They have been forced to live with it. For example, the
> ncr53c8xx and sym53c8xx have their instance lock since day one and as a
> result they have been for years uselessly doubly locked in some places.
> But I didn't want the drivers to rely on the io_request_lock. They just
> are forced to live with it and this was enough.
Indeed, this was not my point. To some extent, the io_request_lock
is pushed down upon the low level drivers from the mid layer. However,
this is not the ugly and hard part to fix. The hard part is the
drivers that then started using it for other generic driver locking.
At this point it's not really obvious what the lock really protects.
> Indeed the io_request_lock reaching low-level driver is ugly and nobody
> ever said it was different. _But_, if we consider the mess-up that existed
> notably the SCSI mid-layer when the SMP race in the block+scsi+drivers
> stack has been discovered, it probably has been a very quick and smart fix
> to use the io_request_lock this way.
>
> One can criticize everything if one just ignores history.
Look, I'm not blaming anyone. It should have been a separate lock
all along, which of course is easy to say _now_. I don't know how
you got it turned this way, I was saying the io_request_lock must
go and the hard part will be some of the low level drivers that do
non-obvious stuff with it. End of story.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
