Resource Tracking for FlightGear: Difference between revisions

Jump to navigation Jump to search
m
Line 217: Line 217:
* Network route table
* Network route table


This information is available in most operating systems, but each OS has their own way(s) providing it.
This information is available in most operating systems, but each OS has their own way(s) providing it. SIGAR provides developers with one API to access this information regardless of the underlying platform. The core API is implemented in pure C
SIGAR provides developers with one API to access this information regardless of the underlying platform.
 
The core API is implemented in pure C  
 
've skimmed through the SIGAR sources on github: https://github.com/hyperic/sigar
 
Turns out, the latest stuff (master branch) already has cmake support, so is really straightforward, and lightweight, to build.
 
For now, I have built the whole thing out of source and installed it system-wide.
However, like you said, it would probably make sense to directly absorb this into $FG_SRC.
 
For testing purposes, this will do - I don't expect many people to use our little patch until it has grown a little more ... I've looked at the demos/examples, and they're also fairly straightforward - for example, see: https://github.com/hyperic/sigar/blob/master/examples/cpuinfo.c
 
This means, that you'll get tons of useful information with just ~15 lines of C code.
So, I am probably going to focus on replacing the hard-coded Linux stuff in the patch with the equivalent SIGAR code, because that stuff is multi-platform, and provides much more, better, and much more accurate information, too.
 
You can see a plethora of unit tests here: https://github.com/hyperic/sigar/tree/master/tests
Some of those could be directly useful in FG, too.
 
Actually integrating this in FG should be straightforward - the main thing is extending our cmake logic to link in sigar, and then add the headers for sigar.h - so that we can directly call SIGAR APIs in our little "process-stats" subsystem (I may end up renaming this "sigar")
 
The required cmake changes can be seen in the CMakelists.txt file in the sigar source tree.
 
Once we are using SIGAR, we should probably get this committed to a topic branch, so that others can more easily test/extend the code over time - I guess it would make sense to see which metrics we'll want to plot using gnuplot ...


== Extending OSG StatsHandler ==
== Extending OSG StatsHandler ==

Navigation menu