libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Read Sub-channel changes
Date: Tue, 7 Jun 2016 09:53:33 -0400

>
> Well, it will be advertised as the improved replacement of
> mmc_last_cmd_sense() and cdio_mmc_request_sense_t, unless you decide
> for a union which represents both formats.
>

For compatibility let's think of keeping both around at least for a release
or so. And it seems a little premature to decide to replace something that
exists with something that doesn't yet.


Currently i put its prototype into  include/cdio/mmc.h  because i lack
>
of better ideas.

This looks very much in spirit like the routines that are in mmc_util.c. So
a better idea is to put it in include/cdio/mmc_util.h.


I plan to claim no own copyright for this.
>

Good. FSF claims to own the copyright for anything that you contribute to a
FSF project. So please send email to address@hidden

As for the proposed message format and retriever API they look great.
Thanks.


On Mon, Jun 6, 2016 at 1:47 PM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> i wrote:
> > > - A sense code parser which picks KEY, ASC, and ASCQ
>
> > The parser is not something that
> > an application program or user would do just for the hell of it.
>
> Well, it will be advertised as the improved replacement of
> mmc_last_cmd_sense() and cdio_mmc_request_sense_t, unless you decide
> for a union which represents both formats.
>
>
> > > - A producer of human readable messages from ASC and ASCQ.
> > >  - Is semi-automatically derived code from SCSI specs acceptable ?
> > I believe it is acceptable.
> > mmc_util.c
>
> Ok. So i will derive a big array of structs from the specs list.
> A function will then look up a (ASC, ASCQ) pair in this list and
> return the associated text.
>
> Currently i put its prototype into  include/cdio/mmc.h  because i lack
> of better ideas.
>
>   /**
>       Convert a triple of key, asc, ascq into a human readable text, which
>       describes the meaning of these codes.
>
>       @param key, asc, ascq give the input triple of error codes from
>              sense data of an SCSI command.
>
>       @return NULL if not enough memory is available. If not NULL it is a
>               pointer to allocated human readable text which has to be
> freed
>               when it is no longer needed.
>   */
>   char *mmc_sense_code_to_text(unsigned char key, unsigned char asc,
>                                unsigned char ascq);
>
> (But shouldn't it be implemented in mmc.c then ?)
>
>
> > if you haven't signed the FSF copyright
> > assignment form, please do so.
>
> I plan to claim no own copyright for this. The most noteworthy part
> of the function is its array of messages, anyways.
>
> ------------------------------------------------------------------------
>
> How about this message format ?
>
>   [KEY ASC ASCQ] : Text from KEY, Text from ASC and ASCQ
>
> Examples from my test code:
>
>   [2 04 01] : Not Ready, Logical unit is in process of becoming ready
>
>   [3 11 00] : Medium Error, Unrecovered read error
>
>   [3 FF 00] : Medium Error, (Unknown SCSI ASC error code)
>
>   [4 09 01] : Hardware Error, Tracking servo failure
>
>   [5 30 00] : Illegal Request, Incompatible medium installed
>
>   [B 00 00] : Aborted Command, (No additional sense information)
>
>   [F 73 03] : Unknown key 15, Power calibration area error
>
> I find it quite annoying that the Linux kernel does not tell the three
> code numbers but only texts which not always match the official ones.
> So i propose to do it better by showing the hex codes first.
>
> If a matching ASC code is found in the list, but no matching ASCQ,
> then the new function  mmc_sense_code_to_text()  returns the text
> of the lowest ASCQ of the matching ASC. This is normally ASCQ 0.
> Especially the manufacturer LG is known to invent own ASCQ values.
>
> ------------------------------------------------------------------------
>
> My prototype for the new retriever of KEY, ASC, ASCQ is this in
>  include/cdio/mmc.h :
>
>   /**
>       Obtain the sense code triple (key, asc, ascq) of the sense reply of
> the
>       most-recently-performed MMC command.
>       This serves for sense data in Fixed Format (0x70 or 0x71) and in
>       Descriptor Format (0x72, 0x73).
>
>       @param key, asc, ascq return the triple of error codes from the
>              sense data.
>
>       @return 1 = the returned triple is valid
>               0 = no sense data available or not in a recognizable format
>   */
>   int mmc_last_cmd_key_asc_ascq( const CdIo_t *p_cdio, unsigned char *key,
>                                  unsigned char *asc, unsigned char *ascq);
>
>
> I propose to prepend this note to the description of  mmc_last_cmd_sense():
>
>       Note: The layout of cdio_mmc_request_sense_t is valid only if the
>             value of  cdio_mmc_request_sense_t.error_code  is 0x70 or 0x71.
>             These values and the values 0x72 or 0x73 can be handled by
>             function mmc_last_cmd_key_asc_ascq().
>
> ------------------------------------------------------------------------
>
> Next tasks will be to create the evaluator and to apply it to the
> MCN retrieval as a first usage example.
>
>
> Have a nice day :)
>
> Thomas
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]