Garmin support: ignore FIT files that aren't dives

[Linus Torvalds]

On Tue, Sep 4, 2018 at 6:47 PM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> 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).

Side note: I considered trying to make the field decoder give some
sane ordering. Because it would definitely help with a lot of cases.

It's essentially what the Garmin automated code generation does: it
seems to turn messages into a full structure, so that you don't have
that "individual fields" model of parsing that we do.

But it ends up being incredibly ugly and painful, and then you'd still
want to have some "individual fields might not have valid data" case,
so it seemed very annoying.

The "struct record_data" thing is kind of a "give me a whole struct",
but in general I'd really suggest trying to avoid it unless you really
have to.

And the reason is partly exactly the "individual fields might not have
valid data". If that ever happens, then the "struct record_data" would
simply have the previous value (or zero, for the first time of a
parse) for that field. It also needs to set the whole "I have pending
data bit" for each kind of structure you record, which adds some extr
a pain.

So that's mainly why I would suggest using the "one field at a time"
model when at all possible. It isn't always possible, but..

What I *really* fear is that some record ends up having the timestamp
not be the first field. Because if we ever end up seeing *that*, then
we're kind of screwed. Right now it really depends on "yeah, we always
see the timestamp first, so we can just do all the sample data as
individual fields without buffering them up".

                Linus