On 2013-01-10 00:10, Linus Torvalds wrote:
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.
The primary purpose of the serial number in the DC_EVENT_DEVINFO event is to be able to uniquely identify individual devices (e.g. for use with the fingerprint feature). For this purpose, it doesn't really matter if the serial number (as returned by libdivecomputer) doesn't match the real serial number (as printed on the hardware). That's why I didn't bother to decode it properly, and just return the raw bytes wrapped in a 32bit integer. In this sense the serial number is more like an opaque device id, and it was not really intended to be shown to the end-user (e.g. for warranty purposes).
Until now, all serial numbers did nicely fit into a 32bit integer, but if there ever happens to be a device where this isn't possible, we can always calculate some hash, just like you already do in subsurface. But of course that will only work if we make no guarantees that the libdivecomputer serial number will match the real serial number.
Jef