[ gpsdrive ] Kismet Integration

Yclept Nemo orbisvicis at gmail.com
Mon Jul 26 15:45:59 AKDT 2010


Really working!

gpsdrive.c diff
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28250#a28250
gpskismet.h
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28251#a28251
CMakeLists.txt
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28252#a28252
gpskismet.c
http://codepad.org/rFXBoMto

No lag whatsoever!

CHANGES
. Added an additional thread for a total of two threads, excluding the
main program. The first thread communicates with kismet, the second
updates the database.
. Fixed small problem with kismet<->gpsdrive communication where, if
select() returned an error, the socket would be set to fd#0
. restructed gpskismet.c. Removed most unecessary variables. Still
needs more work here.
. fixed some thread-safety issues

RESULTS
. no lagging
. might throw off CPU-usage scheduling, probably not though: CPU-usage
calculations should still be accurate (take all threads into account).
However, this shouldn't affect the main program since only one
readkismet thread runs at a time.

TODO
. check sqlite escape functions (database.c, maybe sqlite3_database.c ?)
. debug in valgrind. I want to be absolutely sure gpskismet.c is not
leaking memory
. Memory checks. Right now gpskismet.c uses an unlimited upper memory
boundary. I should just start deleting networks if gpskismet.c reaches
X% of max memory. And related: if the sqlite synch becomes
increasingly backed-up, just skip the synch and delete the entries.
**maybe**
. maybe fooling around with ionices.
. whatever I said above in the previous emails that still applies.
. check that malloc doesn't return NULL and do *something* ??

So if you want to merge these changes into trunk, feel free. (I'd
appreciate it :)


More information about the GPSdrive mailing list