Patches to add basic support for the Suunto EON Steel

[Linus Torvalds]

Ok, this reply didn't go to the mailing list, because the dive log
attachments made it too big.

So I'm just quoting the text here for mailing list posterity, I'm
assuming Jef got the actual attachments and hopefully nobody else
cares (and maybe I shouldn't make my dive data that public anyway).

                     Linus

On Tue, Oct 28, 2014 at 9:51 AM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Tue, Oct 28, 2014 at 8:43 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
>>
>> There are also some header files like unistd.h which don't exist on windows.
>
> Hmm. I wonder why I included them.
>
> Part of it is probably that the whole back-end started out as this
> "suunto hacking tool" that did a lot of "print hex information of the
> packets". That's also why there was no libdivecomputer infrastructure,
> this thing was entirely stand-alone for just trying to gather traces
> and recreate them, and figure out what the things did.
>
> I got no actual information from Suunto, but the fact that many things
> are just text helped. Seeing filenames etc in the dumps etc.. And the
> actual dive dumps have this interesting "each data has its type
> associated with it, and each type has a human-readable type
> descriptor". Which meant that I never needed to guess what the actual
> data means - the problem was figuring out the odd marshaling of the
> data, and the odd packet protocol.
>
> (For example, in the attached dive files, you don't see the crazy
> packet protocol artifacts, because "read_file()" has cleaned it all
> up. Just looking at the textual parts of the packets confused me
> initially, because it turns out that the dive computer re-uses the
> buffer it uses for sending the USB packets, and only fills in the
> parts it needs for a possible partial packet. So the HID packets will
> contain random garbage from the *previous* packet at the end etc etc.
> And while the packets are 64 bytes, the two first bytes of the packet
> is "packet information", so each packet contains just 62 bytes of
> actual payload, yadda yadda).
>
>> Libdivecomputer doesn't log anything on its own. The actual logging is done
>> by the application. That's on purpose. That's for example how subsurface is
>> able to generate a libdivecomputer log directly from the GUI. I believe
>> that's a very useful feature, which certainly doesn't sucks :-)
>
> So the logging I have is for protocol errors, or surprising things.
> Not useful to users. It's more of a protocol verification, I would
> *not* want it to show up in applications.
>
>> Why do you need void pointers here? You're parsing a byte array, which is by
>> definition an unsigned char array. So where do you get void pointers from?
>
> "void *" is the "random byte area" type. It's one of the things C++
> completely screwed up.  It's very useful when you use the helper
> function on random data (that may be embedded in structures etc, or
> give pointers to "uint32_t" etc when you convert from little-endian to
> big-endian etc.
>
> But if there are no cases of that left over, maybe you can convert
> them all to "unsigned char *" ..
>> I know it doesn't support a standard memory dump. But a dump of one dive is
>> fine too. I can use the parser standalone.
>
> I hacked up subsurface to just dump the per-dive data to a
> "dive-%08x.log" file. That's *fairly* close to what the computer does
> internally, although this dumped data contains the date in the first
> 32-bit word, which is what the parser expects. On the dive computer,
> the date is encoded in the filename - see the
>
>     dc_buffer_append(file, buf, 4);
>
> in eon_steel_device_foreach() where I append it to the data buffer
> instead, since the parser doesn't have access to the filename.
>
> (The dive date is *also* encoded in the dive data, but in a very
> inconvenient format with a dynamic type, so I wanted the data from the
> filename for simplicity).
>
> So here are the dumps of the dives I have on that dive computer so
> far, in that "parser format".
>
> That first dive is just me lowering the dive computer into the
> neighbors pool. The other 21 dives are the ones we did in Bonaire.
>
> Dirk has one of the Intel engineers create a contraption to lower the
> thing into the pool multiple times, so that I can see what happens to
> the directory listing when it no longer fits in one "readdir" reply
> (the packets may be 64 bytes each, but they are chained up to be
> replies that can apparently be up to 1kB in size - at least I haven't
> seen anything bigger than that yet. And I don't know what happens when
> the directory listing is bigger than that, because the 22 dives I have
> so far create only about 460 bytes of "readdir reply").
>
>                           Linus