software_concerns
Dal Allan
dal_allan at mcimail.com
Tue Apr 30 23:11:24 PDT 1996
* From the SCSI Reflector, posted by:
* "Dal Allan" <dal_allan at mcimail.com>
*
Hi Bill,
At the risk of making myself very unpopular with a segment of the software
community, you are describing a problem which was self-induced, and has been
telegraphed for years.
If you recall, back when Ordered tags were introduced, there was a small
number of vocal opponents who argued that such behavior was unique to the
parallel bus and any implementation which relied on Ordering would have to
change at some time in the future.
The future is here.
Deterministic delivery of commands is a logical function which should not be
dependent upon the physical attributes of the transport. There are a number
of companies which recognized this and required that their driver writers
avoided certain capabilities of SCSI-2 which relied on the parallel bus.
I can pull a couple of slides out of my old SCSI training material and find
guidelines on Queueing which preach against Ordering, and if it is used,
absolutely prohibit mixing it with Head of Queue. I seriously doubt that
ENDL was the only company inveighing against certain practices (many of the
recommendations originated with clients).
Managing I/O logically consists of programming in atomic units and if there
are subsequent dependencies, not proceeding until an acknowledgment of
successful completion.
I grant you that software which is based on assumptions of the physical
transport can be more efficient than logical management BUT the downside is
it has to change on a physical transport with different characteristics.
Every software driver which relies on implicit or explicit physical
transport capabilities of the parallel bus has a problem.
- I sympathize with you, but I cannot empathize.
- I will support your efforts to identify all the places where drivers can
be affected.
- I will oppose any effort to modify the serial interfaces to behave in the
same manner as the parallel bus.
BTW, we may need to establish guidelines for your proposed effort, because I
disagree with some of your assumptions e.g.
> Each SCSI-3 serial channel presents its own behavioral characteristics
> for channel errors. These affect all layers of the host I/O subsystem,
> including the peripheral driver. If my memory serves me right, one of
> the original objectives of SCSI-3 was the transparency of the physical
> interconnect to the peripheral drivers. In my opinion this objective
> has not be met.
If my memory serves me right, the goal was to preserve the application
software so that the user did not have to re-program.
I believe it was debated that the task of the SIM to map physical interface
characteristics to a peripheral driver. The SIMs could be wildly different
and the Peripheral Drivers could be wildly different and as long as the user
software worked, the objective was achieved.
I would restate your line to read 'one of the original objectives of SCSI-3
was the transparency of the physical interconnect to the application.'
Of course, given that all our memories are affected by selective recall to
justify the arguments we choose to make, we ought to forget the history and
concentrate on understanding the problem being faced. If you can collect the
concerns and the issues it will be a big step forward.
All the best,
Dal
P.S. Do I have to be careful to avoid opening boxes wrapped in brown paper
that are postmarked as being from New England?
More information about the T10
mailing list