On Sat, 10 Feb 2001, Jens Axboe wrote:
> On Sat, Feb 10 2001, Justin T. Gibbs wrote:
> > >Well the driver isnt allowed to hold interrupts off for > 1 tick because
> > >that messes up the clock, and at 1 second the watchdog nmi will reboot
> > >
> > >scsi driver authors therefore need to adjust their drivers
> >
> > If you ask me, it is a bug that the io_request lock is forced on low
> > level drivers at all. 90% of the aic7xxx driver pretends that the
> > io_request_lock doesn't exist, relying instead on a per-controller instance
> > lock. The interrupt handler only aquires the io_request lock for calls back
> > into the mid-layer as it is expected to be held (although the mid-layer
> > almost instantly releases it again). I also immediately release the
> > io_request_lock in all of my error recovery entry points because I don't
> > need the protection and, as you say, we can't lock up the system while we're
> > waiting for recovery actions to complete.
>
> 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 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.
Gérard.
PS: This smart fix was from Linus, if I remember correctly.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
