MMC4r03 mismatch in PREVENT/ALLOW MEDIUM REMOVAL command

Henry Gabryjelski henrygab at windows.microsoft.com
Wed Sep 15 10:30:32 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Henry Gabryjelski" <henrygab at windows.microsoft.com>
*
Good to hear that it's not a mismatch, and it's instead my own mistake
in reading the specification.

Thanks,
.

-----Original Message-----
From: Bill McFerrin [mailto:billmc at tstar.net] 
Sent: Monday, September 13, 2004 9:04 PM
To: T10 Reflector; Henry Gabryjelski
Subject: RE: MMC4r03 mismatch in PREVENT/ALLOW MEDIUM REMOVAL command

Henry,
Table 328 notes that "prevent state" and "persistent prevent state" are
entered differently and indeed are different.  Sub-clause 6.18.3.2 is
titled
"Persistent Prevent State" and discusses that state.  Sub-clause
6.18.3.3 is
titled "prevent state" and discusses that state.

The statement "This command affects the actions of the START/STOP UNIT
command (6.45) and other mechanisms
(e.g. manual ejection / media removal systems)." is found in 6.18.3.3
because it applies only to prevent state, but the statement is not in
found
in 6.18.3.2 because it does not apply to presistent prevent state.

By placing the descriptions in separate sub-clauses, I was hoping to
avoid
the reader confusion that we had with MF.  Alas, I have failed with some
readers.  Perhaps an additional sub-clause titled "Allow State" would be
helpful.  Do you have any  suggestions?

Now, with respect to SPC-3.  The SPC-3 and MMC-4 definitions of byte 4
values do not match except when the Persistent Prevent state is cleared
and
the bit 1 of byte 4 is zero.  SPC-3 does not define "persistent prevent
state", so, relative to SPC-3, we cannot determine if the drive is
either in
it or out of it*.  This is why I am seeking to separate MMC-4 PAMR from
SPC-3 PAMR.

Regards,
Bill

*The belly button on most people is not at all an example of this.

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Henry
Gabryjelski
Sent: Monday, 13 September, 2004 1:54 PM
To: T10 at t10.org; mtfuji5 at avc-pioneer.com
Subject: MMC4r03 mismatch in PREVENT/ALLOW MEDIUM REMOVAL command


* From the T10 Reflector (t10 at t10.org), posted by:
* "Henry Gabryjelski" <henrygab at windows.microsoft.com>
*

The text describing the allowed behavior for a drive is confusing
between the two specifications, Mt. Fuji and MMC.  Looking at recent
versions of each (MMC4r03 and Mt Fuji 5 v1.50), it is clear that neither
specification is clear.  The Mt. Fuji document is the more clearly
written of the two:

//////////////////////////////////////////////////
If the Prevent and Persistent bits are both 1, upon receiving this
command, the logical unit shall disable any eject mechanisms, and all
media after initial drive spin up shall remain locked in the drive until
the host issues an eject request, or the Persistent Prevent status is
reset and the hardware eject mechanism again becomes available.
...
The Persistent Prevent state shall not prevent an eject request from the
host from succeeding.
//////////////////////////////////////////////////

MMC4, however, states the following:

//////////////////////////////////////////////////
This command affects the actions of the START/STOP UNIT command (6.45)
and other mechanisms
(e.g. manual ejection / media removal systems).
//////////////////////////////////////////////////

SPC3 defines the Prevent/Persistent bits very differently, apparently to
deal with embedded changers.  However, SPC3 (r20a) says the following:

//////////////////////////////////////////////////
While a prevention of medium removal condition is in effect, the target
shall inhibit mechanisms that normally allow removal of the medium by an
operator.
//////////////////////////////////////////////////

It would seem that MMC and SPC are suggesting that an eject request via
START STOP UNIT should be rejected by the logical unit if either
Persistent Prevent state or the Prevent state is set.  It also seems
that Mt. Fuji is suggesting that an eject request via START STOP UNIT
should be rejected by the logical unit only by the non-persistent
Prevent state; Another way of seeing this is that the Persistent Prevent
state should only disable hardware ejection controls.

First, please let me know I have made any errors in my understanding on
the above points.  This is a fairly basic area, which affects many
devices.  Information regarding shipped drive behavior is, of course,
also valuable (especially if two very different interpretations have
shipped).

Presuming the above is correct, it then becomes important to reconcile
the MMC draft to both shipping products and Mt. Fuji.  There are no
legacy MMC issues as MMC3 did not define this command (as it was defined
in SPC).  However, because SPC3 has a different understanding of the
Persistent bit, we cannot use this as a reference for this command.  I
would like to suggest that the MMC4 specification adopt the above
definition for the Persistent Prevent bit (Persistent Prevent state
affects only eject requests not from the host, such as hardware based
eject requests(*)).

As always, your consideration and thoughts on these matters is
appreciated.

Sincerely,

Henry Gabryjelski
Software Design Engineer
Microsoft Corporation

(*) The eject button on the front panel of most drives would be a clear
example of this.

-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Henry Gabryjelski
Sent: Tuesday, September 07, 2004 12:25 PM
To: T10 at t10.org
Cc: mtfuji5 at avc-pioneer.com
Subject: Missing IDs for public DCBs?


The MMC4r03 specification describes the format of a couple of the DVD+RW
Disc Control Blocks.  In particular, the Write Inhibit DCB is described
in section 16.27.2.19.2 on page 340, and the Session DCB is described in
section 16.27.2.19.3 on page 341.  However, it seems that the identifier
required to retrieve these DCBs (placed in the "Address" field of the
CDB) is missing from the specification.

Can this ommision please be fixed for the next release of the MMC draft
specification?  Also, if possible, please post these missing values in
the response (so we needn't wait for the next draft).

Thanks,
.


This posting is provided "AS IS" with no warranties, and confers no
rights.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list