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

[Rocky Bernstein]

(Re)reading some of Thomas' proposals

 > Is mmc supported on all platforms ?

That's why the indirection is there. If it turns out not, then that change
is made in the driver. So no, don't go directly to mmc_get_mcn().

> So we have to find an appropriate place where to call mmc_last_cmd_sense()
> and to report the error indicators in human readable form.

mmc_gen_mcn() is a lower-level MMC command that's why it is in
mmc_ll_cmds.c. I gather you recommend running mmc_get_mcn() followed by
mmc_last_cmd_sense() another MMC command,  the package of those two things
constitutes higher-level MMC kind of thing to do. So that would go in
mmc_hl_cmds.c .

And the linux driver would call that routine in mmc_hl_cmds. If it turns
out that for some reason there's a CD drive that one wants to support that
doesn't understand mmc , then one can fall back to the IOCTL call inside
the Linux driver.


On Tue, May 31, 2016 at 5:13 PM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> i wrote:
> > >  - cd-info should report Sense Codes of unexpectedly failed SCSI
> commands.
>
> Rocky Bernstein wrote:
> > Suggest some code to detect errors.
>
> The Linux driver function already detects them:
>
> static driver_return_code_t
> run_mmc_cmd_linux(void *p_user_data,
>     ...
>     /* Record SCSI sense reply for API call mmc_last_cmd_sense().
>     */
>     if (sense.additional_sense_len) {
>         /* SCSI Primary Command standard
>            SPC 4.5.3, Table 26: 252 bytes legal, 263 bytes possible */
>         int sense_size = sense.additional_sense_len + 8;
>
>         if (sense_size > sizeof(sense))
>             sense_size = sizeof(sense);
>         memcpy((void *) p_env->gen.scsi_mmc_sense, &sense, sense_size);
>         p_env->gen.scsi_mmc_sense_valid = sense_size;
>     }
>
> So we have to find an appropriate place where to call mmc_last_cmd_sense()
> and to report the error indicators in human readable form.
>
> In libburn i put such messages into a fifo where the application can
> fetch them and decide whether to display them or not by a "severity" value
> which was attributed to the message by libburn (e.g. "FATAL", "WARNING",
> "DEBUG").
>
> What's libcdio's general strategy for messages from library to application
> ?
>
> -------------------------------------------------------------------------
>
> When interpreting the sense data, i see a model problem in
>   ./include/cdio/mmc.h , typedef struct cdio_mmc_request_sense
>
> The Linux kernel injects synthetic sense data in "Descriptor format"
> (SPC-3, table 13) where KEY is in bytes[1], ASC in bytes[2], ASCQ in
> bytes[3], rather than the "Fixed format" (SPC-3, table 26) which is
> issued by drives. In fixed format, KEY is in bytes[2], ASC in bytes[12],
> ASCQ in bytes[13].
> Further there are no FILEMARK, EOM, and ILI bits in descriptor format.
>
> Descriptor format is identified by bytes[0] == 0x72 || bytes[0] == 0x73.
> Fixed format by bytes[0] == 0x70 || bytes[0] == 0x71.
>
> One would have to define a union, i guess, and interpret .error_code
> to decide which alternative layout to use.
> But what to do about the missing .filemark, .eom, .ili ?
>
> Can we deprecate the cdio_mmc_request_sense_t interface and access the
> meaningful parameters by API calls instead ?
> In that case we could instruct applications to check for
>   (cdio_mmc_request_sense_t.error_code & 2)
> which will be handled only by the API calls.
> If bit 1 is not set, then the cdio_mmc_request_sense_t interface is valid.
>
>
> Have a nice day :)
>
> Thomas
>
>
>