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

[Rocky Bernstein]

> 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.

Sure. That makes sense. The gnu_linux driver generally does things lazily
though. When
the driver is initialized, it doesn't issue CD commands then. If you need
to read information,
then it checks to see if proper initialization is done and does that before
if it hasn't been done already.

See how toc_init is used in the gnu_linux driver.

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

What's the harm of that? An application has the ability to silence warnings
and errors.

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

Ok. But at the debugging level logging a recovered error may be of interest.


On Fri, Jun 3, 2016 at 5:47 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> (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
> SUB-CHANNEL.
>
> 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 :)
>
> Thomas
>
>
>