Reserve and Release for pri

Johnathan Vail vail at harlie.pps.com
Mon Jan 15 14:00:45 PST 1996


* From the SCSI Reflector, posted by:
* <vail at harlie.pps.com (Johnathan Vail)>
   Date: 15 Jan 96 16:09:18 EST
   From: "Smith, Greg" <GREGS at lss-chq.mhs.compuserve.com>


   * From the SCSI Reflector, posted by:
   * <"Smith, Greg" <GREGS at lss-chq.mhs.compuserve.com>>
   >          I propose that reserve and release (ordinary, SCSI-2 style,
   >          not persistent and no extents) be mandatory for SCSI-3
   >          printers and communications devices.
   >
   >          Both of these device models are part of the stream class of
   >          devices which have an implicit state based on previous
   >          commands.  To allow proper control of these devices in
   >          multi-initiator environments, reserve and release are
   >          required.  Therefore, I believe that these commands should
   >          be mandatory.

   It is possible for a printer device to maintain
   multiple states (per initiator) to get around this problem. Concurrent
   PostScript jobs could be run on behalf of different initiators, for 
   example.

The problem with the PRINTER device is that it was never intended for
this kind of use.  It was made to be a controller that connected to
parallel or serial printers and streamed data to them.  Job control
and printer control was expected to reside in the data stream.  Out of
band control in the SCSI mode pages was for things like baud rate and
bit settings.

I have seen many different approaches to putting printers or
imagesetters on SCSI.

Using the PRINTER device type seems logical at first until you look at
how it was designed.  To make it useful you need to add so many vendor
unique extensions and commands that it is no longer generic.  Even
though some large companies have tried their hand at it the SCSI
printer market is too small to get a defacto standard going.

Some printers use the PROCESSOR device model that allows any
arbritrary protocol to be constructed over a very generic device type.
While this may work for one particular device it is not a general
solution.

There are also several that use the DISK (Block Device) SCSI model to
implement their own protocol based on the LBA to stream data, status
and control information.

Given this state of affairs I decided to use the UNKNOWN device type
and just create my own set of SCSI commands from scratch.  Since I
control both sides of the interface myself anyway this approach has
proven to hold up quite well over several years now.

   Obviously, I don't want my 20 pages intermixed with someone else's; this
   could be solved by appropriate buffering in the pre- or post-rendering
   phase of the operation. When buffers become full, write commands could
   be rejected. Many large Postscript film printers have hard disks in them.

I design the firmware for our postscript imagesetters and we came up
against the same problem.  Besides for the convenience of having your
jobs imaged contiguously there are also quality considerations for
high resolution color work.  In this kind of work you want to get your
seperations imaged on the film together to minimize media distortions
and thermal changes over time.

We solved it with our own version of RESERVE and RELEASE.  Since I
defined my own SCSI commands with the UNKNOWN device type I didn't
need to worry about any existing driver compatibility.  I need to have
up to 4 independant SCSI channels operating simultaneously in addition
to multiple initiators so I decided to define a new command instead of
butchering the existing ones.

   Even if the printer designer expects RESERVE UNIT  to be used by the host 
   to
   prevent conflicts, the printer should be sensitive to what state was 
   generated
   by what initiator. For a postscript printer, this may mean generating a 
   'busy'
   status on all other initiators while running a postscript job for a
   given initiator.

Sounds reasonable and coincidentally that is exactly what I do. 

   Likewise, for communications devices, if the communication protocol in
   question supports concurrent independent channels there is no reason why
   different initiators cannot use it concurrently.

   So, I say, the reserve unit should not be mandatory; at least, the 
   argument that
   proper control of these devices *requires* it does not hold, from what I 
   see.

In reality I doubt few people ever see more than one initiator on a
bus.  Many Macs and PCs can't even change their initiator ID and the
physical constraints of a single ended bus make the chances of
multiple initiator rare.


jv


PrePRESS      Johnathan Vail     vail at prepress.pps.com     (508) 262-8354
---------+    900 Middlesex Turnpike   Billerica Massachusetts   01821
solutions     http://www.prepress.pps.com




More information about the T10 mailing list