Re: [Libcdio-devel] Read Sub-channel changes

[Rocky Bernstein]

I'll try to answer the questions. If I've missed something let me know:

Where to implement the three facilities ?
> - A sense code parser which picks KEY, ASC, and ASCQ according to


mm_util.c because this is a utility program in the same way that
 translating error codes to messages is. The parser is not something that
an application program or user would do just for the hell of it. It is part
of some other larger task somewhere else in the library.

- A producer of human readable messages from ASC and ASCQ.
>   Probably to be put into mmc_util.c


Yep. mmc_util.c

 - An evaluator of sense code severity.


 - At what level of libcdio's mmc to interpret the sense data ?


In mmc_hl.c. This *is *something an application program might request. And
it isn't a distinct MMC command so it doesn't go in mmc_ll.c. Instead it is
a higher-level or interpretation kind of thing. The caller would indicate
what the history or context, and give the sense data. And on return you get
what it means.


 I have a 247 line list of KEY,ASC,ASCQ tuples and their meanings derived
> by copy+paste from SPC and MMC. Are there copyright objections  against a
> struct array which i would generate semi-automatically from that list ?


I don't believe so.


 - Is semi-automatically derived code from SCSI specs acceptable ?


I believe it is acceptable.

Copyright on a document is about the text document in large-scale or
wholesale form, more than the ideas it conveys. If say Intel wants to
copyright their instruction-set names (and I think they've done that), then
I believe it has to declare that as a separate item. Creating a copyrighted
manual which lists the instructions and opcodes I don't think is good
enough. For example listing the the chapter headings of a copyrighted book
is okay.  And you can probably publish all sentences with references to a
particular character in a copyrighted novel without violating the
copyright, (unless that character is in every sentence of the novel). In
fact that has been done say with the Harry Potter novels.

Characters of a movie, the movie industry tries to copyright, but to do
that they need to assert that and (at least in the U.S) make an effort to
protect that specifically and bring legal cases. So has the a standards
organization asserted copyright over a mapping of codes to error messages?
And if so, have they tried to protect that copyright by bring suits against
infringers?

However I am not a lawyer, so the link at
http://www.softwarefreedom.org/about/contact/ address@hidden to
get a more definitive answer. Also if you haven't signed the FSF copyright
assignment form, please do so. The email address for that is address@hidden

- What to do with cdio_mmc_request_sense_t ?


I think it has to stay because that's what is defined in the specs. How
applications use it and whether to interpret it is a different matter. So
sure, create other better *additional *structures and APIs to get
information.


On Sun, Jun 5, 2016 at 3:35 PM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> i am pondering about SCSI/MMC sense data handling.
>
> Needed would be the following facilities:
>
> - A sense code parser which picks KEY, ASC, and ASCQ according to
>   the format announced by the first byte of the data. It shall be
>   used instead of cdio_mmc_request_sense_t which is insufficient.
>   This is very low level SCSI stuff. Sense data are defined in SPC.
>
>   Implementation is an easy job.
>
> - A producer of human readable messages from ASC and ASCQ.
>   Probably to be put into mmc_util.c where already an array
>   mmc_sense_key2str[] exists for the KEY component of sense codes.
>
>   Currently there are only two callers of mmc_last_cmd_sense() and
>   thus consumers of sense data: test/driver/mmc_write.c and
>   test/driver/mmc_read.c.
>   They only give mmc_sense_key2str[KEY] and numerical ASC, ASCQ.
>
>   I have a 247 line list of KEY,ASC,ASCQ tuples and their meanings
>   derived by copy+paste from SPC and MMC. Are there copyright objections
>   against a struct array which i would generate semi-automatically from
>   that list ?
>   If this is too much copying for clean copyright, i could offer
>   function scsi_error_msg() from libburn/spc.c. It shows some traces of
>   my cluelessnes before i learned more about SPC. On the other hand it
>   contains only message texts which i wrote by hand after having reason
>   to pick them from the copy+paste list. I.e. quotes embedded in own
>   work, not copied text.
>
> - An evaluator of sense code severity.
>   mmc functions shall call it after a low level SCSI operation has been
>   performed. The evaluator should decide what kind of problem the sense
>   code describes:
>   - no problem
>   - ignorable problem
>   - desired action failed, advise to retry
>   - desired action failed, retry seems futile
>   - relation to drive is broken
>  The caller would specify how to report problems:
>   - no report by evaluator
>   - debug
>   - warning
>   - error
>
>   The caller of the evaluator will have to combine its generic evaluation
>   result with particular expectations of the MMC transaction.
>   E.g. START/STOP UNIT with Eject bit shall not take offense if the
>   sense code reply says that the tray is now open and thus no medium
>   is detectable. With READ(10) the same sense code would indicate a
>   severe error.
>
>   I am clueless at what mmc level to put this.
>   mmc_util.c ?
>
>   In libburn this is not very clearly handled. The evaluation is a second
>   job of scsi_error_msg(). The reaction is scattered over several
>   functions and not always exactly appropriate. (E.g. when START/STOP UNIT
>   with ejection reports that there is no medium after it has done its job.)
>
> --------------------------------------------------------------------------
> Opinions and decisions, please:
>
> - Where to implement the three facilities ?
>
> - Is semi-automatically derived code from SCSI specs acceptable ?
>
> - At what level of libcdio's mmc to interpret the sense data ?
>
> - What to do with cdio_mmc_request_sense_t ?
>   It represents only fixed format sense data but not descriptor format.
>   Nevertheless it is an overlay struct for the array of sense data bytes.
>   This needs some safety cap at least in the API documentation. Like:
>   cdio_mmc_request_sense_t is only valid if
>     (cdio_mmc_request_sense_t.error_code & ~2) == 0x70
>
> --------------------------------------------------------------------------
>
>
> Have a nice day :)
>
> Thomas
>
>
>