Re: [gpsd-dev] ✘GPSD_API

[Gary E. Miller]

Yo Bernd!

On Wed, 13 Apr 2016 22:04:56 +0200
Bernd Zeimetz <address@hidden> wrote:

> hi,
> 
> > I've been looking at gps.h and at these two constants:
> > 
> > #define GPSD_API_MAJOR_VERSION 6       /* bump on incompatible
> > changes */ #define GPSD_API_MINOR_VERSION 1       /* bump on
> > compatible changes */
> > 
> > It is not clear to me what constitutes a compatible channge and
> > what is an incompatible change.  
> 
> I understand it as in:
> - stuff that only adds symbols to libgps and/or adding stuff to the
> api without breaking it: compatible change
> - removing or changing symbols in libgps: incompatible change

Yeah, but the details in particular applications elude me.
 
> > For example, was the recent addition of oscillator_t osc to
> > gps_data_t a compatible change that should have incremented the
> > minor rev?  
> 
> I'm pretty sure that breaks the abi as you are chaging the size of
> structs.

I don't think it does change the size of gpsdata_t since oscillator_t
was slipped into a union already bigger than it is.  I think it should
been a minor version bump since it should not affect existing programs.

But if I bump the major rev soon not worth thinking about much.

> > I'm guessing that if I added a field to satellite_t skyview, which
> > is in gps_data_t, that would be an incompatible change?
>
> same here.

Since the size of skyview affects the location of later elements in
gpsdta_t I can how adding a field would break things.

I'm guessing your view in the BSD world is that you really want to hold
off on any sort of api change between major BSD revisions.  To allow
for mix and match binaries as much as possible.

> Also you might want to look into
> /* FIXME! next lib rev need to add a place to put PPS precision */

Yeah, since I'm getting ready to break the API I might as well
get as many changes in as I can.

satellite_t needs URA added.
devconfig_t is probably the place for PPS precision

what else?

> > I also have some other changes that likely need to go in gpsdata_t.
> > For example, there are two distinct types of satellites_used and
> > satellites_visible.  One type is the number reported by the GPS and
> > the other is a could of sats seen so far in sucessive GPGSA dn
> > GPGSV.  But gpsdata_t has place for only one type and they keep
> > over-wrting each other...  

I'm thinking satellites_visible_cnt and satellites_used_cnt can get
biried in nmea_t and nt affect the API.

> you also might want to read
> http://www.catb.org/esr/structure-packing/

Even embedded systems now have gobs of memory.  As soon as we use
python, or any other garbage collection, the gross handling of RAM makes
saving a byte here or there in C ludicrous.  Page frames allocated by
the kernel are now 4k or even 4M, so months of work packings bytes would
be needed to save enough RAM to eventually save one page frame.

I just took a look at my desktop host, gpsd is about the smallest thing
running.

I'm not saying to be wasteful, but there are way more important things to
spend time on now than packing structures.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpmvnM6GuIbG.pgp
Description: OpenPGP digital signature