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: Tue, 07 Jun 2016 16:29:40 +0200

Hi,

i wrote:
> > improved replacement of
> > mmc_last_cmd_sense() and cdio_mmc_request_sense_t,

Rocky Bernstein wrote:
> For compatibility let's think of keeping both around at least for a release

I do not propose to remove it from the API.
It's just that  mmc_last_cmd_key_asc_ascq()  does its job without
the caller needing to know about SPC and sense data formats.


> > prototype of mmc_sense_code_to_text()
>  put it in  include/cdio/mmc_util.h

Now i wonder why i did not find this file when looking for a place.
(Probably because i looked in lib/driver/mmc rather than in include/cdio.)

Ok. The prototype is in include/cdio/mmc_util.h .

-------------------------------------------------------------------------

About the evaluation of sense codes:

I am testing a function now. Some questions arise.

- How to represent the result in the architecture and style of libcdio ?
  Enumeration, Macros ? Are there any proposals for symbol names ?

  I need to express this outcome

           0 = no problem
           1 = problem which needs no direct reaction
               (but it may announce particular future failures if not
                proper action is taken)
           2 = desired action failed, retry may bring success
               (timeout or abort due to repeated failure are responsibility
                of the caller)
           3 = desired action failed, retry seems futile
           4 = relation to drive is broken

  and this instruction which is given by the caller

           0 = no report by evaluator
           1 = report as debug
           2 = report as warning
           3 = report as error


- How much shall my user experience with the Linux kernel influence
  my reading of SCSI specs ?

  SPC-3 says that key 0xB invites for retry.
  My (mostly hearsay) experience is that key 0xB indicates a broken
  relation between kernel and drive.

  Shall the evaluator really follow SPC-3 and advise retry ?
  (I fear that the next SCSI command might not return.)
    
-------------------------------------------------------------------------

Have a nice day :)

Thomas




reply via email to

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