On Wed, Jan 9, 2013 at 12:31 PM, Linus Torvalds
<torvalds(a)linux-foundation.org> wrote:
>
> This is a small 2-patch series that makes the dive computer nickname
> infrastructure be a more generic "device info" structure instead, and
> splits it out into "device.[ch]".
Side note: as discussed with Dirk, the intent of this series is that
we can save other information about the dive computer (serial numbers
etc) in the device info structure.
However, quite frankly, looking at what we get at least right now from
libdivecomputer, I doubt it is worth it. The "serial nr" thing is an
integer, which is unlikely to actually match any serial numbering on
the package or anything like that.
For example, the Suunto serial number that libdivecomputer gives me
for the helo2 is 389152795. The *actual* serial number of the device
is "23500027".
Guess what? Serial numbers are strings, not numbers. Look around,
you'll notice that manufacturers almost always encode serial "numbers"
with letters etc. The libdivecomputer interface is wrong.
It so happens that the Suunto serial number strings are strings that
have all numbers, but they aren't *one* number. They are four bytes
representing two numbers each, and the "23500027" string is actually
the four bytes 23 50 00 27 (0x17 0x32 0x00 0x1b). And libdivecomputer
has incorrectly parsed those four bytes as one number, not as the
encoded serial number string it is. So the value 389152795 is actually
hex 0x1732001b, which is 0x17 0x32 0x00 0x1b, which is - 23 50 00 27.
IOW, the serial numbers libdivecomputer gives us are useless. You
could perhaps turn them into an actual serial number string on a
per-vendor (or per-device) basis, if you know the vendor rules. The
Suunto vendor rules *seem* to be pretty simple, based on the two
devices I have (the Vyper Air clearly uses the same encoding, giving
another 8-byte string). Other dive computers? Who knows?
Anyway, the current libdivecomputer "serial number" information is
wrong. It has some information, but the information is in the wrong
format, and you need vendor-specific knowledge to turn it into the
right string.
As a result, there's no point in having subsurface save it. We can use
the integer form for the device ID hash, and that's all it is actually
useful for. It would be good if libdivecomputer continued to give the
old "numeric serial number" for that use, but to make it *useful* we
also need some interface to get the actual vendor string
representation, so that we can save that. If we get the correct serial
numbers in the proper format that the vendor uses, *that* information
wou;ld be useful to save for things like warranty purposes etc.
It could be as simple as a new libdivecomputer callback ("given this
serial *number*, what is the string for it?"), but it would probably
be better to expand the current DC_EVENT_DEVINFO event to simply give
us a string in addition to the number. Because it's not necessarily
the case that all serial number strings can even be represented as a
single 32-bit integer.
Linus
