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