[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Read Sub-channel changes
From: |
Leon Merten Lohse |
Subject: |
Re: [Libcdio-devel] Read Sub-channel changes |
Date: |
Sun, 29 May 2016 16:36:17 +0200 |
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
- [Libcdio-devel] Read Sub-channel changes, Leon Merten Lohse, 2016/05/27
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/05/27
- Re: [Libcdio-devel] Read Sub-channel changes,
Leon Merten Lohse <=
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/05/29
- Re: [Libcdio-devel] Read Sub-channel changes, Leon Merten Lohse, 2016/05/29
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/05/30
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/05/30
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/05/30
- Re: [Libcdio-devel] Read Sub-channel changes, Leon Merten Lohse, 2016/05/30
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/05/30
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/05/31
- Re: [Libcdio-devel] Read Sub-channel changes, Thomas Schmitt, 2016/05/31
- Re: [Libcdio-devel] Read Sub-channel changes, Rocky Bernstein, 2016/05/31