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

[Thomas Schmitt]

Hi,

Leon Merten Lohse wrote:
> I looked over the changes proposed by Thomas Schmitt in April

I feel guilty that the todo topic "Learn to understand what git gestures
Rocky expects from me" sunk deeper and deeper here. Real life interference.

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>


> Nevertheless, I do not see the point in issuing the command twice -
> first to query the length.
> While the spec (MMC-4 [1]) allows the device to return less than the
> requested data, the data structure has fixed length.

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

My reason to do it in libburn were fatal failures on USB of Linux 2.X.
I learned the trick from growisofs, which did not fail on the same drive.
Some time later cdrecord joined the club for fixing a similar problem on
newer Linux.

In case of READ SUB-CHANNEL, a counter value of 0 is a valid reply.
(MMC-4 6.29.3.2: "A Sub-channel data length of zero indicates that no
 Sub-channel data block is included in the returned data.")


Have a nice day :)

Thomas