This was really creepy stuff. Last updated in April, 2006 to work with
kernels > 2.6.12. I consider this "fobar" (fscking obsolete beyond all
recognition) and doubt anyone still uses this. If you do, blame me. :)
This patch ought to be small and simple ...
The reason why it's not is me wanting the entropy data out of struct
information. This means update_entropy() can not be used anymore, as it
uses this globally available object.
The solution I am presenting here is quite messy regarding header
includes. Hopefully this will go away soon as I plan on creating some
sort of "OS library" containing all OS specific routines and defining
macros for easier capability checking in the non-specific code. This on
the other hand means we'll need "wrappers" around OS specific objects,
but that's not as bad as it seems - having non-specific text objects
only will definitely clean up the code, and capabilities can be checked
where they should be.
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?
* Drop all need_mask alterations (no idea why there were here at all,
but surely not sane since they are missing in the non-linux
functions).
* Drop the update delay for update_meminfo(), as parsing /proc should
not lead to abnormal overhead.
* Check for x_initialised from inside update_x11info(), so we can call
it unconditionally.
All ERR()'s are renamed to NORM_ERR() and box to mbox so that they don't
clash with things in ncurses.h .
Ncurses is enabled by default when building conky but can be disabled with
--disable-ncurses .
At the moment configure doesn't check if ncurses is actually available.
I'm adding support for ncurses so that we can make as much things as possible
that are only available in X11 also available in console in the future.
Added support for X alignment across multi-lined objects (i.e., using
$alignr with $exec). This may be a bit buggy. Disabled OpenMP code
until GCC's implementation stabilizes (it's causing too many problems).
A couple Lua API changes.
Basically, I just added three new process properties (io_read, io_write, io_perc - representing
the amount of I/O done by the process during the update interval) and $top_io, that sorts
processes based on io_perc.
Atm, it's completely #ifdef'd, since it requires kernel support. But that creates some wierd
looking syntax at some places, so it may be better to remove some ifdefs. It even may be
possible to completely remove the ifdefs (ie. convert them to #ifdef linux) since the code will
compile just fine even if the kernel doesn't support I/O accounting. I'll leave that for someone
else to decide.
When you started "$updates|${addr eth0}" displayed "0|No Address",
after the first update you got something normal like "1|192.168.0.1"
This patch should fix this.
This diff moves Linux-specific parts of diskio.c into linux.c and uses
the remaining diskio functions to correctly implement this functionality
for FreeBSD. It also hooks diskio.c to the FreeBSD build.
Signed-off-by: Brenden Matthews <brenden@rty.ca>
Moved interface_up(...) from linux.{c.h} to common.{c,h} and taught it
to check for ENXIO as well to make it work on FreeBSD.
Signed-off-by: Nikos Ntarmos <ntarmos@cs.uoi.gr>
Despite this is actually not much code and could stay inside linux.c as
well, this makes sense as I want to combine smapi and ibm-acpi
functionality. Virtually every user of a notebook made by IBM/Lenovo
will want both, so this should be a feature not a bug.
Besides making the ibm-acpi objects being built optionally, this should
not change anything to the code flow.
This was a bug, not a feature. From the FreeBSD manpage rtentry(9):
| Vt struct sockaddr *rt_gateway;
|
| The "target" of the route, which can either represent a destination in
| its own right (some protocols will put a link-layer address here), or
| some intermediate stop on the way to that destination (if the
| RTF_GATEWAY flag is set).
So for a default route with "dest" and "mask" both zero, either
RTF_GATEWAY is present, or "gate" is zero.
