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: Rocky Bernstein
Subject: Re: [Libcdio-devel] Read Sub-channel changes
Date: Thu, 9 Jun 2016 22:18:17 -0400

Ok - great! That works then without any of the complications and problems
brought up before.

Still, libcdio also is a library for issuing mmc commands, so one might
also replicate this in mmc.c or mmc_hl_cmds.c.

But let's leave that for later after things have been worked out better on
the driver side.

On Thu, Jun 9, 2016 at 12:56 PM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> Rocky Bernstein wrote:
> > mmc_get_mcn_isrc_private() I guess needs something better than the
> existing
> > mmc_read_subchannel(). No problem. Create something new that has the
> right
> > interface, i guess it would pass back a cdb.
>
> There is already such a back interface which is extensible without
> changing the prototypes of existing functions. It currently stores only
> the sense data, but could well store the CDB, too.
>
> lib/driver/generic.h has without my modifications:
>
>   typedef struct {
>     ...
>     /* Memorized sense reply of the most recent SCSI command.
>        Recorded by driver implementations of cdio_funcs_t.run_mmc_cmd().
>        Read by API function mmc_get_cmd_scsi_sense().
>     */
>     unsigned char  scsi_mmc_sense[263];   /* See SPC-3 4.5.3 : 252 bytes
> legal
>                                              but 263 bytes possible */
>     int            scsi_mmc_sense_valid;  /* Number of valid sense bytes */
>     ...
>   } generic_img_private_t;
>
> Instead of letting all lowest-level mmc functions hand back the CDB
> by a function parameter, one can simply stuff the CDB into
> generic_img_private_t where one would add:
>
>     mmc_cdb_t scsi_mmc_cmd;
>     int scsi_mmc_cmd_len;
>
> This has the additional advantage that there are much fewer implementations
> of p_cdio->op.run_mmc_cmd() than there are callers of this function
> pointer.
> So if we let the implementations record the CDB, we have much less effort
> than if we let all callers tell the CDB to their callers up to a layer
> where
> it is finally used.
>
> The prototype of new function mmc_evaluate_last_sense() could then
> omit the parameter  mmc_cdb_t *cdb  because it could be retrieved via
> CdIo_t *p_cdio.
> This means the callers would not need to know the exact CDB but only
> the intention of the MMC command. E.g. whether failure is fatal or
> just a small inconvenience.
>
>
> Have a nice day :)
>
> Thomas
>
>
>


reply via email to

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