Note that the code does not only use a pre-processor generator for
defining the print functions, but also for their prototypes. Sadly, this
generated a conflict in mboxscan.c which this patch resolves, too.
In the linux kernel 2.6.31 and above, device data can either be in
/sys/class/hwmon/hwmonDEV or /sys/class/hwmon/hwmonDEV/device.
Just stat'ing for the latter doesn't work since it can exist but not contain
the required data (see https://bugs.launchpad.net/bugs/435571 for details).
The patch could be improved to keep in memory the right location of the data
on the user's system instead of trying each time, but, is it worth doing it?
A cleaner but more ugly solution would be to include text_object.h in
every header containing struct text_object definitions. But this
apparently triggers a big mess, since text_object.h itself includes
custom headers. Forward defining struct text_object is obviously the
mostly simple solution until there is a bigger header include review
cleaning it all up.
* minimise core code hooks
* drop useless exporting of private functions (and make them static)
* reorder functions in eve.c so no prototypes are needed
* drop massive header include and add double include barrier in eve.h
While testing, I found two already existing bugs:
* the variable 'a' passed to iconv_convert() needs to be passed by
reference in order to allow for the desired side effect.
* Somehow the trailing junk after an iconv_conversion to a shorter
string messes things up (and gets printed!). I couldn't exactly find
out why this happens, but setting (*p) = 0; solves this problem.
-d was broken because fork-to-background was done after the update thread creation, so the
threads ended up in the wrong process. This delays the thread creation until after the fork.
Originally, I was experiencing sporadic lockups when reading inotify_fd;
which is strange, since it is protected by select(). This should fix it
despite of the original problem.
Create each thread upon registration of the callback function, then use
semaphores to signal when it's time to update and when updating is
finished.
Many thanks to pavelo who originally came up with the idea for this.
Yes, I also thought these are monotonic counters. But it seems like they
are not, at least sometimes the value decreases by 1 leading to a very
very high cpu usage percentage being printed.
