> Worse, we tried to do it with driver specific locks and we got all kinds
of
> corruption. The major problem was that the drivers would lock against
> themselves but when they called into the mid level code (especially
drivers
> that don't use the new_eh code) the mid level code would trash scsi
commands.
> Think of things like two different drivers servicing different cards on
> different interrupt vectors on an SMP machine...
I can believe that this would lead to all sorts of trouble.
> > > I am proposing a means by which we can get all of the low-level
drivers
> > > to pry their grubby little fingers off the io_request_lock. I am
thinking
> > > of adding a "smp_safe" flag to the host template. If this flag is not
set,
> > > it indicates that the low-level driver is expecting the current
behavior (in
> > > other words, it assumes that io_request_lock is held when each of it't
> > > entrypoints is called). Defining it this way means that with no
changes to
> > > the low-level drivers it is possible for things to work correctly.
> >
> > Go ahead. I think this approach allows a smooth transition. If you want,
you
> > can even make it dependent on some CONFIG_SCSI_SMPLOCK option, so that
one
> > can easily revert to the old behaviour, if one meets problems. That
would
> > allow the driver's authors to test for this option and do their locking
just
> > when this MACRO is set. It will be ugly code (lots of ifdefs), but
you'll
> > have that anyway for drivers which have a unique codebase for 2.2 and
2.4
> > (what many driver authors like, and so do I).
> > define something which we can test on in hosts.h:
> > if (SCSI_SMP_SAFE) spinlock_irqsave (&my_lock, &flags);
Ah, yes. I had forgotten that a lot of drivers use a common codebase
for 2.2 and 2.4. Yes, it would look ugly for drivers to do this, but it
would be quite doable. In fact, many drivers appear to have abstracted
their locking into macros already, mainly to support even older kernels that
predate some of the SMP work.
> I'm perfectly happy with something like this. My only request is that the
> driver shouldn't need to worry about locking around entry points into the
mid
> level code (aka, my driver shouldn't have to lock around the calls to
> scsi_done() which is a distinct problem now for all non-new_eh using
drivers
> at least). That means the various driver->mid-level code entry points
need to
> do appropriate locking so that the mid level code doesn't trash itself.
The mid-level should be completely self-sufficient WRT locking right
now, and the only exception as I noted before is that the old error handling
code is just as fragile as before. On this end of things I would strongly
prefer not to touch it, as it appears to be working now with the new
queueing code.
My thinking is that drivers must first switch to the new error handling
code before attempting to turn this on. There is an old saying "Mustn't
tease the bear..." :-).
At some point once things settle down a little more, I am probably going
to take a stab at converting some of the legasy drivers to the new error
handling code and to otherwise bring them uptodate. This would be a 2.5
kind of kernel project, of course. Testing would be a nuisance as I
wouldn't have hardware to test on, so I suppose I would make an attempt to
find testers. I don't know whether it is doable or not, but I would like
to be in a position to jettison the old error handling code in time for 2.6
or the next stable release after 2.4.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
