On Mon, 6 Sep 1999, Matthew Jacob wrote:
> > This still seems backwards. It should be going
> >
> >
> > [ll_rw_blk] [sg]
> > +-------------+
> > |
> > Card Driver
> > (calls)
> >
> > [ SCSI Libraries ]
> >
> >
> > The card driver should have a library of support routines, not an immovable
> > layer of glue above it. For a simple dumb card with the 2.3.17 ll_rw_blk
> > scatter/gather features its likely to be doing something conceptually like
> >
> >
> > while((cmd=request_to_scsi(req, ISA_BOUNCE))!=NULL)
> > {
> > [issue command to hardware]
> > add_timer(..) for abort/reset
> > }
> >
> > Smarter cards might want to use the queueing in the library, others may not
> > but control belongs card level.
> >
>
> Not necessarily. Scheduling and complicated error recovery is a property
What scheduling ? Error recovery must allow to deal with some ordering.
If your scheduling of IOs is rather blind and does not care about any
ordering required to recover from an error, you will never be able to
really recover from anything.
The only mechanism I know about, that allows performances when everything
works fine and that allows some recovery when an error occurs (typically
CHECK CONDITION or any other scsi error) is the CAM3 specification about
SIM queueing/freezing/unfreezing that applies to SIM device queues and
that requires actual operations on SIM device queues to be exclusively
performed by SIM.
Basically, when everything if fine, the device CCB queuing works normally
for performances, but when an error occurs the SIM device queue is frozen
by the SIM, allowing the application client to have control on CCB
executions and order of execution (using appropriate CCBs).
By the way, I donnot have seen yet this mechanism correctly implemented.
For example, it is not so in FreeBSD-CAM, and I can argue on this point
if people want me to do so.
> of interactions with the whole system- not one bus.
What whole system ? An sub-system for example may need to have some
control on not yet completed IOs it has initiated in order to be able to
recover from IO errors, but probably not on all IOs generated by the
system. The same applies to a device (model) driver, or to applications
that deal directly with the devices. Any recovery that involves the whole
system interactions is not possible to ever work, in my opinion.
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
