Patches to add basic support for the Suunto EON Steel

[Dirk Hohndel]

On Tue, Oct 28, 2014 at 01:02:07PM -0700, Linus Torvalds wrote:
> On Tue, Oct 28, 2014 at 12:44 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> > Is this per sample data or per dive date? So I think this is a
> > DC_FIELD_STRING in libdivecomputer nomenclature.
> 
> DC_FIELD_STRING would work, yes.
> 
> I think it would likely be but be slightly annoying as the
> DC_FIELD_xyz model is driven by the application, so now the
> application has to query these strings, which in turn means that you
> have to either count them up-front, or use the index model (and
> perhaps iterate until you get NULL's back or an error code?).

Ah. Hadn't thought of that.
Having DC_FIELD_STRING return an array of pairs of strings sounds
challenging. Maybe "keep calling it until it returns two empty strings"
is a reasonable way of doing this. I like this better than having to first
get a number of strings.

> The DC_SAMPLE_xys model is nice for the kinds of things where the
> divecomputer just gives a random number of entries, because that's
> obviously how the samples work too.

Yes. Maybe it's just my mindset that's too inflexible here. I think of
DC_SAMPLE things as stuff that happens "during the dive". And I think of
DC_FIELD things as stuff about the whole dive. Maybe I need to drop that
categorization.

Jef - would either of these work for you?

> I guess I could even convert the serial number etc to be those kinds
> of things, and use this instead of the DC_FIELD_DEVINFO thing I wrote.

It would certainly make things nicely consistent. Let's see what Jef
thinks of this direction.

/D