[PATCH] Preferentially use existing device ID when setting serial number

[Linus Torvalds]

On Mon, Jun 20, 2016 at 6:47 PM, Steve <stevewilliams at internode.on.net> wrote:
>
> What if you have multiple deviceids associated with the same serial number (I seem to get a new entry every firmware update)

So that "new device ID due to firmware change" happens only with the
DEVINFO model, for all kinds of bad reasons.

The bad reasons all have good intentions: because we keep track of
firmware version etc by device ID, if we want to keep track of the
same dive computer having multiple different firmware versions (for
different downloaded dives), then we need to have separate device ID's
for them all in order to have a unique identifier for all the cases.

It turns out to be a horrible model, because it causes the same
"download multiple times" problem, but the intention was good.

And sadly, once the device ID depended on firmware ID, it was hard to
fix - impossible, if you didn't want to lose firmware version data (ie
different dives being done with different firmware, and the ability to
see that).

But I guess we could try to use a similar fix as for the serial number
ambiguity: once we've picked a particular device ID, we'd stick with
it, and we'd look up old dive computers to find the one we should
stick with. And just say "you lose old firmware info"

But the real deeper problem we have (and this is what I was hitting my
head against for hours) is that it would really be good to get rid of
the device ID thing entirely, but we don't have a reliable replacement
that also saves things like firmware per dive.

With the string-based serial numbers, there's a good device ID: the
hash of the serial number actually works quite well, and the string
interface also avoids the problem with ".. but but firmware versions
can change", by simply exposing the firmware version as another string
entry.

So for the EON Steel, the per-dive divecomputer save area ends up
looking like this:

  model "Suunto EON Steel"
  deviceid 72dfb54c
  ...
  keyvalue "Serial" "#p1437019"
  keyvalue "FW Version" "1.2.18"
  keyvalue "HW Version" "71.2.0"
  keyvalue "Battery at start" "Charge: 100%, Voltage: 4.152V"
  ...

and it all works fine. But that model really *depends* on the whole
new "use strings for things" thing that I implemented in
libdivecomputer explicitly for the EON Steel.

And sadly, it seems that Jeff Driesen (who maintains upstream
libdivecomputer) absolutely hates the string interface. So the EON
Steel backend is pretty much the only one that implements it.

Dirk added some partial support for the string model to a few other
cases, and in fact the Shearwater Predator back-end is one of them. So
my patch should actually help that case too: at least in the *future*,
firmware updates should always pick one of the existing device ID's,
because the serial string case that picks one of the existing ones
will trigger.

                      Linus