Oceanic / Aeris A300CS multipage patches

[Dirk Hohndel]

On Tue, Oct 14, 2014 at 10:11:03PM +0200, Jef Driesen wrote:
> Looks good to me. Just one comment. Are you aware that you are only creating
> aligned reads for the profile data, and not the logbook data?

That's interesting. When I traced this it got me aligned reads everywhere.
I wonder if this was a coincidence... more to test...

> >BTW: if you'd prefer we could add another field (something like
> >"mixed_pagesize_support") to oceanic_atom2_device_t and then could enable
> >this for those dive computers with 128 byte pages where we can test and
> >verify that this works. That would make it less of a special case for the
> >A300CS. I wasn't sure which version you'd prefer, so I implemented the
> >A300CS specific one (or actually, the 256 byte page specific one), but I'm
> >happy to go the other direction if you think that's better.
> >
> >Actually, the more I think about it, maybe that's the better way in case
> >Oceanic / Aeris come out with a 256 byte page read model that doesn't
> >support mixed paged sizes...
> 
> I'm not sure if this really helps. A model that doesn't support mixing page
> sizes, will likely no longer support the smaller page size and always
> require the larger page size. (That appears to be what's happening with the
> F11.) But your "mixed_pagesize_support" patch does exactly the opposite: it
> falls back to using single pages only. But why would you enable bigpage in
> the first place? Just keep it at one, and you're done. Or am I missing
> something else?

The mixed pages were introduced when I removed the caching code.
But we could completely remove that and simply do the hand full of extra
redundant reads and not switch page sizes for any of the models.

But I guess I shouldn't even offer that since you seem fine with the first
set of patches:

> With that in mind, I think your first set of patches is the better one.

Forget what I said above :-)

> [The more I think about it, the more I actually like the idea of the
> caching. Internally we can always use a fixed page size, regardless of the
> requested size. Thus completely transparent to the calling code. But okay,
> let's proceed with your latest patches now, and we'll look at what needs to
> change for the F11 once we have more info about that. [Me thinking out load
> now] I wonder if we would even need a full cache? Since libdivecomputer
> always reads successive pages, we basically only need the latest page again.
> Another thing that we may have to watch out for, are those few models with
> an inaccessible last page. But I think I've only seen that for devices which
> support the B1 read, so that should be fine.]

I can bring the cache back as well, no problem.

Literally, tell me what you want, I'll implement it :-)

/D