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

[Thomas Schmitt]

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