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: Thomas Schmitt
Subject: Re: [Libcdio-devel] Read Sub-channel changes
Date: Mon, 06 Jun 2016 19:47:56 +0200

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]