On Fri, 27 May 2016 11:11:35 +0200 "Thomas Schmitt" <[email protected]> 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: <[email protected]> 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
