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

[Leon Merten Lohse]

On Fri, 27 May 2016 11:11:35 +0200
"Thomas Schmitt" <address@hidden> wrote:

> Do i get it right that you refer to this proposal ?
>   http://lists.gnu.org/archive/html/libcdio-devel/2016-04/msg00017.html
>   Date: Sun, 03 Apr 2016 20:16:30 +0200
>   Message-Id: <address@hidden>

Yes.

> This is the most safe approach in the presence of broken drive
> firmware and overly optimistic low-level device drivers. If the
> command replies a data counter before its data, then first require
> only this counter. So no kernel developer can ask "why do you require
> data which are not available".

It probably is. And I would agree with you in most cases. And when we
are dealing with more data, we should certainly stick to that rule. But
here, I really do not see the benefit. On the other hand we lose
simplicity and need an extra mmc call.

According to the MMC spec, the `allocation length' parameter is the
maximum amount of data the drive may return. I agree that we should not
request more than the size of the expected data structure. Although it
is allowed, it might give some drives a hiccup.
But requesting the length from the spec really should not.

cdrkit/icedax also does this in one call, as far as I can see. I might
be wrong though, because I just looked over the code and never actually
ran a debugger on it.

Also the majority of the code in mmc.c in libcdio just uses one query.
One exception is the READTOC call for CD-Text. This said, I guess that
some functions would actually benefit from this. Especially those, who
request larger amounts of data.

td;dr: I would rather not have the second query.

Best regards
Leon