proposal to obsolete Operational Change Event
kenji-tokumitsu at hlds.co.jp
Mon Sep 8 19:11:05 PDT 2003
* From the T10 Reflector (t10 at t10.org), posted by:
* "Kenji Tokumitsu" <kenji-tokumitsu at hlds.co.jp>
I agree with Katata-san's proposal and support his proposal.
I am sorry, I can not attend September MMC-4 meeting.
Hitachi-LG Data Storage, Inc.
From: keiji_katata at post.pioneer.co.jp
[mailto:keiji_katata at post.pioneer.co.jp]
Sent: Friday, September 05, 2003 4:25 PM
To: T10 at t10.org
Cc: mtfuji5 at avc-pioneer.com; twg3 at ml.cds21solutions.org
Subject: proposal to obsolete Operational Change Event
I would like to propose mark Operational Change Event as obsolete. The best
way is remove it once. Then add new method properly that host needs really.
I find a lot of " an Operational Change Event shall be generated" in
mmc4r02c.pdf. So I check why such information is written so much in the
mmc4. Then I find following sentence in REVISION HISTORY PDF page 10.
Clause 7 . sub-clause 7.3 MRW Mode Page
Morph Event is not a defined term. Changed to Operational Change Event.
This is not correct partially. Originally Morphing idea means when media
event is reported, the MMC device capability may be changed drastically.
The change may be same as "Inquiry data change" of SCSI world. For example,
"Peripheral Device Type" of device that has CD-ROM disc could be 05.
"Peripheral Device Type" of device that has DVD-RAM/+RW 3G disc could be
07. But DVD-RAM has DVD Video related capability and C/DVD-ROM drive can
support DVD-RAM disc to read. These are not covered by SBC, only MMC could
cover this. Then Morphing idea is introduced. At the same time, Persistent
PREVENT/ALLOW MEDIUM REMOVAL command and Persistent Prevent State is
introduced. Host controls media change (device morphing) including disc
eject by eject button.
At the same time, many software vender had hang up trouble when user press
eject button then DVD disc is ejected during DVD Video playback.
Morphing idea allows that MMC device can change from Read only device to
any other (Block device/write once device etc.) and opposite. Host can lock
the Morphing by Persistent PREVENT/ALLOW MEDIUM REMOVAL.
Here is an important point.
Point 1: Original Morphing means Profile change, does not mean current bit
of Feature descriptor.
Current bit of Feature is changed by host command. So host knows the change
of Feature before device reports it. "Operational Change Event" does not
show that host command is succeeded or not. It only shows that something is
changed. So in the discussion of Fuji group, "Operational Change Event" is
confirmed as option. Because no Feature requests to support it.
Unfortunately, in the discussion of MMC WG 01-288r0.pdf, this was rejected
by technically in-correct reason. According to 01-288r0.pdf, "Operational
Change Event" was connected with Immed bit and "Device Busy (class 6)
event" as I reported before.
Here is another important point.
Point 2: "Operational Change Event" itself is meaningless for host.
Originally it is option.
I get not small number of blames that difficult event makes bad
implementation of products. W*QL H*T 9 and 10 MMC Test software requests
Operational Change Event implementation as "shall report it is supported
but shall not report the event in reality". Pioneer DVD-ROM and DVD-R/RW
drives perform as this. So more than 10,000,000 units of drive report 16h
in "Supported Event Classes" (this means I support "Operational Change
Event"), but never report "Operational Change Event".
Here is 3rd important point.
Point 3: Operational Change Event can not work in the real market.
According to 03-216r0.pdf, all were decided in July.
Please all members send your comment to my proposal and pointed items via
* 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