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

[Thomas Schmitt]

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