proposal to obsolete Operational Change Event

keiji_katata at post.pioneer.co.jp keiji_katata at post.pioneer.co.jp
Wed Sep 10 00:25:38 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*

Hi Henry,
If you could not attend 2nd MMC WG day, it will be obsoleted (I think).

To spy all of the possible command including future command not exist now
is very hard. I agree. If you have oprational change event, medium event,
you need to check only GetConfig command. You need not know futur command
too.

But you already say the problem to spy the GetConfig command. Because many
software can issue GetConfig command from variouse layer/timing in
multi-task environment. Your purity software also have directx interface.
So someone other than Henry, can monopolize the Operational change event.
How do you control this?

Closing sessin on blank CD-R should cause Operational change event. Because
blank CD-R get a session. Then the next session is closed, what is happend.
No event is generated. Becasue all Features of CD-R becoms current now. In
case of CD-R, only first sector write, first session close can cause event.
No more event is not reported even if many sessions are created.
Same thing can be done by write command. If a software changed file system
on the medium in the drive by write command, no event is reported. But the
content in disc is changed at all. New file system driver needs to be
loaded. Do you need this change?

I belive this issue can be controled inside of host. For example, if a
software make big change on media, the software send a message aroung
software modules in OS.

For the formatting in progress item, already current software can handle
this without Operational change event. OS can format Harddisk drive,
DVD-RAM disc, CD-RW disc and etc. Why do they work well without Operational
change event? Why do you need operational change event?

Using evnet notificatoin to get progress indication of formatting is wrong.
This is not event. Only issuing Request Sense command, you can get the
progress indication of formatting +RW. Device will report "No media" >
"getting ready" > "formatting" > "Ready". Why do you need to use Event
reporting for this case?

Best regards,

Keiji Katata
PIONEER CORP.





"Henry Gabryjelski" <henrygab at windows.microsoft.com>@avc-pioneer.com on
2003/09/09 02:55:29

mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(J

$BAw?.<T(J:     owner-mtfuji5 at avc-pioneer.com




$B08 at h(J:  <mtfuji5 at avc-pioneer.com>, <T10 at t10.org>
cc:    <twg3 at ml.cds21solutions.org>
bcc:
$B7oL>(J:  RE: proposal to obsolete Operational Change Event


This proposal concerns me; specifically:
"Current bit of Feature is changed by host command. So host knows the
change
of Feature before device reports it."

The current use of the OpChange event is provided to allow the host OS to
know about behavioral changes in the device.  This includes both feature
list changes and profile changes.

The above quote from the below description presumes that the host OS can
know, at the time of the writing of the host OS, all possible commands that
could change the features on the device; In addition, the host OS would
need
to "spy" on all CDBs sent to the device, to detect those commands which
would change the capabilities of the device.  Alternately, the description
below presumes that the host OS is initiating all IO to the device from a
single driver/location.  i.e. All CDBs are constructed from a single point.

Unfortunately, neither of the above presumptions is correct in the Windows
OS.  The first presumption may hold true on the day the OS ships, but any
new commands or variations of commands would render it invalid.  The second
presumption is also false, as CDBs are constructed by all of the following:
1) Class driver (CDROM, CLASSPNP)
2) Filter drivers (IMAPI, 3rd parties filters)
3) User-mode programs (SCSI_PASS_THROUGH(_DIRECT), ATA_PASS_THROUGH, etc.)

Therefore, since it is not possible for the host to always know when the
device should change (as the host cannot know all CDBs which cause this) it
is only by the use of the OpChange events that the host can reliably detect
that a feature list has changed, and modify which commands are allowed or
rejected.

Later, you write:
"Point 2: "Operational Change Event" itself is meaningless for host."

This is also untrue, although for your particular device it may be
acceptable for the current OS.  Without this event, the class driver cannot
update allowing write commands to randomly-writable, target-defect-managed
media after a user-mode program sends a FORMAT_UNIT command (or other
vendor-unique command to enable such behavior).  It is also not possible
(as
stated above) to know all possible CDBs to watch for.

You also suggest that, just because a test written to help validate device
behavior doesn't seem to require an event to occur, that the obvious
solution is that such a test does not *want* the event to occur.  Perhaps
instead, the test either has a bug, or does not exhaustively test all
possible scenarios and some devices may slip through with such an error in
the firmware.  Either way, pointing to a test whose purpose is to *help*
create compliant firmware instead of referring to the specification is, in
my opinion, an erroneous way of thinking.

You make a 3rd point, but do not provide any supporting evidence.  DVD+RW
drives require the correct implementation of the OpChange event to allow
random writing to the media while background formatting is in progress.  In
a closed system (such as a set top box or consumer player) your comments
are
correct.  However, in the more complex PC environment, I believe it would
be
a very poor decision to remove this event.

This will be an interesting discussion, I am sure...
.



-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]
On Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Friday, September 05, 2003 12:25 AM
To: T10 at t10.org
Cc: mtfuji5 at avc-pioneer.com; twg3 at ml.cds21solutions.org
Subject: proposal to obsolete Operational Change Event


Hi all,

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
t10 reflector.

Best regards,

Keiji Katata
PIONEER CORP.













*
* 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