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

[Rocky Bernstein]

> Would this be ok for get_mcn_linux(), too ?

Yes. What was done for for get_isrc_linux is what should be done for
get_mcn_isrc. The main point is to encapsulate
MCN-ness and Linux-ness in the linux driver.

If at this point everything is running SCSI, that's great.

As for where to put the call to sense data. If it is something that will
occur across several OS's then it goes in mmc_hl.c, if it is specific to a
particular OS then it goes in the driver for that OS. And it's okay to
guess wrong as the routine could start out say in the driver and then
migrate itself into mmc_hl.c when another OS needs the same code. And the
routine in mmc_hl.c or driver will be responsible for making sense of the
sense data.


On Wed, Jun 1, 2016 at 5:06 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> i wrote:
> > > Is mmc supported on all platforms ?
>
> Rocky Bernstein wrote:
> > 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().
>
> I made the direct call because ((CdIo_t *) p_cdio)->op.get_mcn() gets
> a different parameter than mmc_get_mcn().
>
> The call for ISRC converts such a parameter back to (CdIo_t *).
> In lib/driver/gnu_linux.c :
>
>   static char *
>   get_track_isrc_linux (const void *p_user_data, track_t i_track) {
>
>     const _img_private_t *p_env = p_user_data;
>     return mmc_get_track_isrc( p_env->gen.cdio, i_track );
>   }
>
> Would this be ok for get_mcn_linux(), too ?
>
>
> Whatever, my scruples against omitting the function pointer layer
> would rather be about operating systems with no known SCSI passthrough
> facility, rather than about drives which do not understand MMC.
> I myself never saw a drive which did not claim to work by MMC. There
> are old traces of drives which came with a custom controller card:
>   http://www.tldp.org/HOWTO/BootPrompt-HOWTO-9.html
> The controllers were no general SCSI ones. Question is whether their
> command set was non-SCSI.
>
> libburn is SCSI-only. In ten years of development i did not get a single
> user report about drives which would not work by ioctl(SG_IO).
>
>
> > > 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.
>
> > I gather you recommend running mmc_get_mcn() followed by
> > mmc_last_cmd_sense()
>
> Yes. Something like that.
>
> My problem with the libcdio architecture is that lower-level MMC
> is the expert to produce a human readable message, but that it is
> far away from the human or application who shall read the message.
>
> The converter from Sense Data to error message needs SCSI knowledge
> in order to distinguish the Fixed Format data from the drive from the
> Descriptor Format data which the Linux kernel injects.
> (Typically with KEY = 0xB "Command aborted". Google for "Sense Bytes: 72"
>  to see how cdrecord gets confused by this format. MMC prescribes to
>  use only Fixed Format. But Linux or bus controllers do not obey.)
>
> So if the application shall actively obtain the human readable error
> message, then we'd need a new API which reaches down to lower-level MMC.
>
> There still remains the problem that an API call of libcdio may employ
> more than one SCSI command and thus may yield more than one set of
> Sense Data.
> If the application calls the (new) error text producer afterwards,
> it will currently only see the last error reply.
>
>
> Have a nice day :)
>
> Thomas
>
>
>