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, 2 Jun 2016 04:59:12 -0400

If understand what you've said so far, you would instead have code like:

static char *
get_mcn_linux (const void *p_user_data) {
  char * psz_mcn
  const _img_private_t *p_env = p_user_data;
  psz_mcn = mmc_get_mcn( p_env->gen.cdio );
  // issue SCSI INQUIRY
  // interpret result and take appropriate action like
  // issue ioctl(CDROM_GET_MCN). If that doesn't work
  // issue, cdio_error() and return NULL
  // or cdio_warn(), or cdio_info() and return pzs_mcn.
  // if no problem
  return psz_msn;
}

Since a MCN is a fixed number of characters, I suppose one can even get
creative and change the next somehow. But this is kind of gross, may break
assumptions caller may have
about MCN so  probably shouldn't even suggest this.

On Thu, Jun 2, 2016 at 3:37 AM, <address@hidden> wrote:

> Hi,
>
> sorry for breaking the mail threading. I have to reply from web interface
> because my
> mail provider has problems with SMTP authentication.
>
> Rocky Bernstein wrote:
> > 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.
>
> If we may rely on MMC (like with ISRC) then this would be
>
> static char *
> get_mcn_linux (const void *p_user_data) {
>
>   const _img_private_t *p_env = p_user_data;
>   return mmc_get_mcn( p_env->gen.cdio );
> }
>
> I am testing this now.
>
> Would there be some indication reachable via p_user_data which tells
> whether the drive reacts on SCSI command INQUIRY and identifies itself
> as CD device by value 5 in bytes[0] of the reply ?
> (If it did not reply properly, one could try ioctl(CDROM_GET_MCN).)
>
>
> > 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,
>
> It is yet undecided whether the KEY=0xB sense data stem from controller
> hardware or from kernel drivers. The Descriptor Format for sense data is
> specified in SPC-3.
> MMC-5 6.30.1 states nevertheless:
> "MM Drives that support only a 32-bit LBA format, shall return only
>  fixed format sense data."
> So it is quite sure that the sense data do not stem from the drive.
>
> I am still riddling how to combine reliable reporting of unexpected
> or severe SCSI sense data with the necessary modesty of a library
> when it comes to fprintf(stderr).
> The application should be able to decide what gets printed and it
> should have means to obtain the messages as strings.
> Does libcdio already provide such means ?
>
>
> Have a nice day :)
>
> Thomas
>
>


reply via email to

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