[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
>
>
>
- [Libcdio-devel] Place for test documentation, Leon Merten Lohse, 2016/06/03
- Re: [Libcdio-devel] Place for test documentation, Rocky Bernstein, 2016/06/03
- Re: [Libcdio-devel] Place for test documentation, Leon Merten Lohse, 2016/06/04
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/04
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/05
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/06/05
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/06
- Re: [Libcdio-devel] Read Sub-channel changes,
Rocky Bernstein <=
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/07
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/06/07
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/08
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/06/08
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/08
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/06/08
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/09
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/06/09
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/06/09
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/06/09