[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: scdbackup
Subject: Re: [Libcdio-devel] Read Sub-channel changes
Date: Thu, 2 Jun 2016 09:37:57 +0200


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 :)


reply via email to

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