[Top][All Lists]

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

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

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] Read Sub-channel changes
Date: Fri, 03 Jun 2016 11:47:04 +0200


(Sorry for replying late. It turned out that the ESMTP server of GMX
 does not perform the two-liner "AUTH PLAIN - 334 - password - 235"
 any more but only the one-liner "AUTH PLAIN password - 235".)

Rocky Bernstein wrote:
> If understand what you've said so far, you would instead have code like:
> get_mcn_linux (const void *p_user_data) {
> ...
>   // issue SCSI INQUIRY

I would rather issue INQUIRY when libcdio opens and first inspects the
drive. The result could be recorded in or underneath CdIo_t for later use.

The necessity for this depends on the decision whether libcdio shall still
support drives which do not obey the specs and command set of SCSI.
If this legacy support shall be uphold, then the INQUIRY result could
be a guide for the Linux driver (and others) when to use the MMC functions
with their finer control opportunities.

> // ... If that doesn't work
> // issue, cdio_error() and return NULL

Shall the error message really be initiated by the platform driver ?

The lowest level which knows the intentions of the caller would be
mmc_get_mcn_isrc_private() in mmc.c. It already handles MCVAL==0
and could well handle if sense data have been fetched after READ

It seems to me that a warning message would be appropriate if
sense keys other than 0 (nonsense) or 1 (recovered error) occured.
Then the result should be handled like MCVAL==0 (or TCVAL==0).

(I have a more general handling of sense code in libburn. But when
 i followed its wires yesterday, i rather got some new points for
 the long-term todo list. Not yet ready to bragg with it. Grmpf.)

Have a nice day :)


reply via email to

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