[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-dev] [PATCH] Factor out library upcalls

From: Matt
Subject: [gpsd-dev] [PATCH] Factor out library upcalls
Date: Sun, 24 Aug 2014 18:13:21 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

Ok, the attached patch against git HEAD factors out the upcalls from the core library to application code into a separate C file that manages callbacks stored in file-static data, which is then linked into libgpsd. There are only two such upcalls that I found: reporting and writing to devices, in applications gpsctl, gpsdecode, gpsmon, test_geoid and test_packet, and in the Python glue gpspacket.c . But there may be more that I missed.

It doesn't cause any new problems in terms of build warnings, splint, cppcheck, or testregress. That's all the testing I've done; I haven't attached live hardware yet.

Although storing the callback functions in file-static data is certainly less than ideal, storing the callbacks in some client structure would require passing that structure around everywhere, which would be ugly. File-static data is no worse than the application-global linker namespace as we have now. I have not investigated thread-local storage. Can GPSd be built without support for pthreads?


Previously, applications depending on libgps[d] were free to define (or not) certain symbols, and we depended on the linker and runtime linker to search application modules before shared libraries, and search both for all undefined symbols. With this patch, these symbols are always defined in the library with sensible defaults, but the application is free to install its over-rides if it wants to, which has to be done from application code. The intent is that there never be an undefined symbol in a library, which application code must then define.

Samuel, if you merge this with your Android work, I believe it will obviate your moving of gpsd_write and gpsd_report from gpsd.c to libgpsd_core.c (with which it will conflict). Could you please give it a try? It should help.

Regards, matt

On 21/08/14 05:02, Eric S. Raymond wrote:
ukyg9e5r6k7gubiekd6 <address@hidden>:
-Library symbols and linking --By default, gpsd doesn't
explicitly links libgps (Tried imloads with no luck as well).
This results in unix_to_iso8601 being UND. Android Linker fails
to link gpsd binary because of this. Patched SContruct to
explicitly link libgpsd against libgps.
This makes me nervous.  I want to look for a less intrusive way to
fix the problem you're seeing.
I too saw this under mingw. I came up with some fix but I forget what
I did now. I'll have a look at my diffs.
I'd like to see another patch from you, improving the Android port,
that addresses this issue.

Note, I believe I've fixed your sys/select.h issue in the masters.  It
looks to me like the library you're using has a sys/time.h that is not
SuS-compliant; if it were, this wouldn't be an issue.

--Moved gpsd_write and gpsd_report from gpsd.c to libgpsd_core.c.
The library libgpsd uses these symbols from gpsd whereas it
should be the other way around if libgpsd was to be used by
another binary. These symbols are marked UND which makes the
android linker to fail loading gpsd binary.
Alas, this patch is flat wrong; it violates the way the code is
layered. These functions are callouts from the library that are
*intentionally* defined different ways by different binaries.  We
need to find a way to beat your linker into doing the right thing
I wouldn't really call it layering since it's a bi-directional
dependency. More like an unhealthy co-dependency of the sort that
psychiatrists warn against :-)
Eh?  There's nothing odd or co-dependent about hook functions being used
in a library.  The intent is to allow applications to specify their
own reporting functions for errors encountered by the library.
The approach I took in the mingw port, and which I think is superior
to attempting to make the linker do what you consider to be the Right
Thing on all platforms and all weird linkers, was to add some function
pointers with sensible default values into libgpsd_core.c, then add
some entry points into libgpsd that let the calling binary set those
function pointers to those it supplies, if and when it wants to.

This is probably buried in a whole lot of other unmergable/confused
crud in my mingw fork, but I can dig it out into a separate diff if
someone wants.
I'd like to see this patch.

I second the motion to have a header which does nothing but define
HAVE_* constants - does not include any other headers, nor do any
typedefs nor macro definitions nor declarations nor anything else.
Call it gpsd_config.h or anything else. My preference would be for
'config.h', but what's in a name?

I believe there exists a legitimate need to find out what the
underlying system does and doesn't have (ie what Sconstruct found),
without also pulling in random other headers that could cause trouble
or even merely slow compilation.

As a specific example, on mingw, anything that pulls in windows.h
incurs large parse overhead and lots of namespace pollution; and
almost all Windoze headers of interest pull in windows.h sooner or later.
Gotcha.  It's a good idea.  Might not happen before 3.11; I'm trying to get
that out quickly, in time for the next Debian freeze, and am thus avoiding
code changes that can easily be deferred (that is, other than bug and port

Attachment: factor-out-library-upcalls.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]