Software Write Protect Proposal

PAT LaVARRE (PAT LAVARRE) LAVARRE at iomega.com
Thu Feb 1 08:47:59 PST 1996


* From the SCSI Reflector, posted by:
* PAT LaVARRE (PAT LAVARRE) <LAVARRE at IOMEGA.COM>
*
> ... the header bit ... already defined ...
> I felt that this was the most logical
> method ...

I share your feeling but regretfully
conclude we missed our chance back before
SCSI-2, as follows.

> What makes this any more "clearable" than
> a reserved bit in a mode page? ... Most 
> people just to a read/modify/write on the
> pages and could/should do the same for
> the header.

You indeed can read the _contents_ of a mode
page and then write it back and hope thereby
to change nothing.

By contrast, per SCSI-2, you can end up
writing one's into reserved and not-defined
areas if you write back a mode parameter or
page header just as read.

How specifically?  SCSI-2 reserves the PS
bit and the disk device-specific DPOFUA bit
in mode select headers, and leaves "not
defined" the disk device-specific WP bit.

People have responded to this complicating
restriction by clearing the entire header
read, as a matter of course.  In particular,
they respond this way when they first
encounter a product that implements the PS
or the DPOFUA bits and see their software
suddenly die.

In practice, software is more likely to
clear a new mode header bit than it is to
alter a new mode page bit.

> If a device is in a state such that the
> write protect is on, then it knew that it
> turned on the write protect and it knew
> how to do it.

Possibly not.

Software sold in the PC/Mac world often so
completely lacks integration that code from
one vendor control some features and code
|from another will control others.  Both
programs talk on the bus - taking turns.

For example, we support the SP save pages
bit of a mode select command precisely in
order that software from one vendor can edit
the mode pages while software from other
vendors flatly ignores mode pages.

Furthermore, software in the real world gets
confused.

For example, one of the things I like about
our implementation of prevent-medium-removal
is that we refuse stop-and-eject commands
while medium removal is prevented.  A
write-cacheing layer that prevents medium
removal need not trust the user interface to
send down an eject command only when
appropriate.  (PC's being what they are, the
eject command would not necessarily pass
through the write-cacheing layer.)

Analogously, placing the write protect bit
in a mode page instead of a mode header
reduces the level of trust required to
believe that software unaware of the new
write-protect bit will leave it set.

Pat LaVarre
p.lavarre at ieee.org






More information about the T10 mailing list