Suunto Eon 16/19 dives

[Linus Torvalds]

On Wed, May 20, 2015 at 4:04 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> I suspect that my "readdir()" thing has the potential for the same
> issue, and unlike "read_file()" I don't know ahead of time exactly how
> many bytes I'm supposed to get.
>
> I think I know what the protocol expects me to do (I should look at
> the first reply packet to see the final size - right now I just
> _verify_ the final size against it), but that will be a larger patch.
>
> I'll think some more about this, but expect another patch later today.
> The patch I sent should be fine for hopefully fixing the case that hit
> Guenther, so this "more patches to come" is more about future-proofing
> than anything else.

Ok, this is the more complete patch. It goes on top of the previous
one, although I guess technically it really ends up undoing it
entirely because we just do the reading differently.

It ended up being a bit bigger than I hoped for, but I think the end
result is good. It's *much* more explicit and careful about sizes of
the replies from the dive computer and there is no more "read more
packets until you can get no more" kind of logic, we now use the
expected size and read that many bytes. That's clearly (in hind-sight)
how the protocol was designed - my original "partial data packet marks
the end" model came from how I noticed the big patters before noticing
the specific details in the headers of the reply sequence.

Again, "it works for me". Clearly more testing would be good, but
since this tightens up the logic, if I had gotten things very wrong,
it would be very obvious. So I think it should be good.

                                Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-suunto-eon-steel-be-more-explicit-about-transfer-siz.patch
Type: text/x-patch
Size: 8988 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150521/4161e754/attachment.bin>