Write Protection Model
keiji_katata at post.pioneer.co.jp
keiji_katata at post.pioneer.co.jp
Tue Dec 21 18:28:49 PST 1999
* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello Ai san,
About class 1 event, we can make it mandatory if logical unit supports
class 1 event. So I would like to change the sentence, "If logical unit
supports class 1 event reporting, logical unit shall generate class 1
event."
About Feature, I would like to introduce new idea that is partially
persistent Feature. In this idea, reporting is persistent, but setting is
option and in sometime it is available, in other it is not available. I
agree that this is different with current Feature and Current bit
definition. Other way is "adding the RWP (Reporting Write Protection
status) bit into core feature". Write Protection feature shows PWP setting
ability (this is Tokumitsu san's opinion).
Which is better?
Best Regards.
Keiji Katata
PIONEER CORP.
reply to aiai at dsd.mei.co.jp
to: Keiji Katata/Pioneer
cc: mtfuji2 at dt.wdc.com, mmc at dt.wdc.com, t10 at t10.org
subject: Re: Write Protection Model
Hi Katata-san,
---Start of the original message ------------------------------------
>From: keiji_katata at post.pioneer.co.jp
>Date: Mon, 20 Dec 1999 14:02:08 +0900
>To: aiai at dsd.mei.co.jp
>Cc: mtfuji2 at dt.wdc.com, mmc at dt.wdc.com, t10 at t10.org
>Subject: Re: Write Protection Model
>
>
> Takaharu Ai, <aiai at dsd.mei.co.jp> wrote:-------------------
>
> Dear Kohda-san,
>
> I ams sorry for late responce but we have some comments
regarding
> Pioneer's write protection proposals.
>
> Here are Matsushita's comments and counter proposal regarding
Write
> Protection Model.
>
> 1) MECHANISM STATUS command
> - In the Mt.Fuji3 specification, no information regarding a type
and
> other property of a medium in each slot is in the Slot Table
Response
> format. The purpose of this command is to obtain an information of
the
> current situation of a "Slot" not a disc. It means that a property of
a
> medium shall be maintained by Host not Logical Unit. So we think
the
> extension in your proposal is not needed.
>
> 2) Event Reporting
> - According to you proposal, Logical Unit shall generate Class 1
Event
> when the Write Protection status is changed. But my understanding is
that
> the Class 1 Event is generated when the Logical Unit's behavior
is
> changed by for example changing its microcode. But the Write
Protection
> status is based on the disc not the Logical Unit. Even if the PWP bit
is
> changed to one by a command, no Feature is added and no Microcode
is
> changed. So we think the Class 1 is not appropriate.
> - Our counter proposal is to generate Class 4 Event instead of Class
1
> Event. Because the changing of PWP is very similar to change medium.
>
> 3) Write Protection Feature
> - The meaning that Feature which is returned by GET CONFIGURATION
command
> is that the function which is specified by the Feature is "supported"
by
> the Logical Unit regardless of the function is currently executable
or
> not. In your proposals, the Feature indicates that the Logical Unit
can
> report the write protection status.
> It means if the READ DVD STRUCTURE command with Format code C0h
is
> "supported" by a Logical Unit, this Feature shall be reported
regardless
> of the command is executable or not.
> - The Current bit shall be set to one when the functionality indicated
by
> the Feature is currently executable. According to Pioneer's proposal,
the
> Write Protection Feature indicates to support the functionality to
report
> the Write Protection status of the medium though READ DVD
STRUCTURE
> command with Format code C0h. When a media is inserted, this command
is
> executable I think. So the Current bit is set to one when a
writable
> medium is mounted.
> - This is to clarify, but does the SWPW bit is set to one if the
Logical
> Unit "support" the READ DVD STRUCTURE command with Format code C0h
even
> when the mounted medium is write protected by the write protect tab
on
> the cartridge?
>
> Best Regards,
>
> Takaharu Ai
> SDBD/AVC/MEI
> Osaka, Japan
> ------------------------------
> About "1) MECHANISM STATUS command", so I remove PWP from the Slot
Table
> Response format. The CWP in the Slot Table Response format
provides
> "Partial Medium Load for MAM Access" like functionality. Some device
can
> read CWP status without loading the cartridge into its play position.
I understand the intention of your proposal. I agree with you.
>
> About "2) Event Reporting", I disagree completely. 1st reason is this
is
> class 1 event, not class 4 event. 2nd reason is reporting class 4
event
> may confuse the system. Usually the system which supports writing on
the
> media by particular file system shall supports reading the media and
the
> used file system. There is no advantage useing class 4.
My understanding is that the Write Protection Status change Event is same
as
Formatting.
When an unformatted DVD-RAM medium is mounted in the Logical Unit, the
Random
Readable and Random Writable Features with Current bit set to zero are
returned. If
the medium is formatted, these Features become Current.
This is the same situation as the Write Protection status change. When a
Persistent
Write Protected 4.7GB DVD-RAM medium is mounted in the Logical Unit, the
Random
Writable and Formattable Features with Current bit set to zero are
returned. If the
medium is write permitted through SEND DVD STRUCTURE command, these
Features become
Current.
According to the Mt.Fuji3 document, the Class 1 event is applied to inform
that
medium has been formatted. But the Class 1 Event itself is not mandatory
for
Formattable Feature. I think some of devices does not implement Class 1
Event and
it is still Mt.Fuji3 Compliant device. Changing of Write Protection status
should be
the same as Formatting. Generation of Class 1 Event shall not be mandatory.
So I would like to change my proposal to as follows,
8.4 Event Reporting
When Write Protection status of mounted medium and/or Logical Unit is
changed
(e.g. all of Write protections are cleared or one of them is set to
active), any
Features that allows erasing/formatting/writing on media are changed, the
Logical
Unit may generate Class 1 Events.
> About "3) Write Protection Feature", I may not understand the all
meaning
> of this comment. But it may be as follows. Reading write
protection
> status and Setting write protection status shall be separated same
as
> "Random Readable Feature" & "Random Writeable Feature". But it
is
> redundant, it is too much for such a write protection issue, I think.
If
> no media status or ROM media in the device is defined as write
protected
> status because any write shall be failed, reading write protection
status
> can be "Persistent". But in December meeting, we decided that
without
> media, Read DVD Structure command with format code C0h shall
be
> terminated with Check Condition. Then it is not Persistent.
> However, there is no need to use current bit to show "you can see
the
> write protection status now". Because if media is installed, you can
see
> the write protection status that is defined by the media
specification
> always.
I am sorry for my unclear explanation.
I meant your proposal had an inconsistency about the definition of the
Feature and
the Current bit.
<<from the definition of the Feature>>
According to your proposal, the Write Protect Feature indicates a Logical
Unit has
an ability to report the write protect status by READ DVD STRUCTURE command
with
Format code C0h. This means that the Current bit of this feature shall be
set to
one when the ability to report the write protect status is active, i.e.
when the
READ DVD STRUCTURE command with Format code C0h can be executed normally,
this
Feature shall be Current.
<<from the definition of the Current bit>>
According to your proposal, the definition of the Current bit is that the
bit shall
be set to zero if the Logical Unit can not set/release the PWP status on
the
mounted media surface. This means the Write Protect Feature shall indicate
a
Logical Unit has an ability to change PWP status of the media.
The meaning of my original proposal was that the definition of the Current
bit
should be changed to as follows,
Current bit shall be defined as in Table 109-Feature Descriptor generic
format on
page 228. This bit shall be set to one if the Logical Unit can report
write
protect status on the mounted medium surface through READ DVD STRUCTURE
command
with Format code C0h.
Best Regards,
Takaharu Ai
SDBD/AVC/MEI
Osaka, Japan
*
* 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