Garmin support: ignore FIT files that aren't dives

Linus Torvalds torvalds at linux-foundation.org
Tue Sep 4 18:47:41 PDT 2018


On Tue, Sep 4, 2018 at 6:32 PM Dirk Hohndel <dirk at hohndel.org> wrote:
> > On Sep 4, 2018, at 6:11 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> >
> > I took all your commits. Minor changes, like not checking that
> > device_index, because it actually changes *after* you've already seen
> > the values.
>
> As you have seen, there are several devices inside your Garmin.

Yes, yes. But because you checked device_index, you actually got the
*wrong* data.

Because you first got the firmware for device index 0, and took it,
but then you gfot the firmware field for device index 1, and you took
that *too*, because the device index=1 hadn't actually shown up yet.

> Clearly we need to use the device_info message that is for the correct device_index.

No, we probably just need to use the *first* one.

The fields inside the record aren't ordered (well, they are, but the
ordering is an insane one based on the size of the field).

But the various messages do end up being ordered. In fact, the FIT
specification even enforces some of the index ordering, although it's
not spelled out for the device_index one. But other index cases (the
generic message index and part index) are literally specified that
they have to start with zero and increment sequentially.

So the assumption that device_index 0 is the first one is actually a
fairly safe one just going by some of the other indexing FIT files do,
unlike the assumption that device_index comes before the other fields
(which is not only not safe, it's not actually the case).

                 Linus


More information about the subsurface mailing list