My understanding is that SENSORS_API_VERSION should be the same
as $(LIBMAINVER)$(LIBMINORVER) in lib/Module.mk. This means that
the first digit of SENSORS_API_VERSION needs to be incremented whenever
API *or* ABI changes, because we have to increment LIBMAINVER even if
only ABI changes to avoid program breakage.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
SFP modules measure the transmit power of the lazer. The sensor has
expected minimum values, and alarms when these minimams are reached.
Add support to sensors to print these.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Marvell Ethernet PHYs can contain a temperature sensor, which the kernel
exports as an HWMON device. The PHY is on an MDIO bus. Add support for
this bus types to libsensors. The sensor is then displayed by sensors(1):
socaipsbus02100000ethernet02188000mdioswitch0mdio01-mdio-1
Adapter: MDIO adapter
temp1: +54.0°C (crit = +100.0°C)
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Add support for sysfs attributes temp[1-*]_min_hyst (already
implemented by drivers adt7x10, lm77 and lm92) and
temp[1-*]_lcrit_hyst (no known users yet.)
When gathering the attributes of each hwmon chip, libsensors uses a
temporary structure in memory to order and group all the attributes
into features. This temporary structure used to be a single array with
room for every possible attribute/subfeature. While simple, this
approach required to predefine a maximum number of per-type sensor
that could be handled.
In order to get rid of this arbitrary limit, which we hit and had to
raise three times already, I changed the temporary structure to an
array of dynamically allocated per-type subattribute arrays. This lets
us not allocate any memory for types which aren't implemented by a
given chip, and more importantly, this lets us reallocate room for
more attributes of a given type as needed.
I decided to allocate chunks of 8 attributes at a time, as this seemed
a good compromise between two frequent reallocations and
over-provisioning. It could be tweaked if needed.
Icing on the cake, I benchmarked this change on two different systems
and it results in performance gains. The total heap usage as reported
by valgrind is down by 50% on average, with peak memory consumption
(as reported by valgrind's massif) also down by 43% on average. The
total instructions count (as reported by valgrind's callgrind) is down
by 11% on average, with measured execution time also down by a few
percents. Valgrind rocks, BTW.
I have some ideas to optimize the memory allocations further, but I do
not expect such a huge gain from them. They may not even improve peak
memory consumption as massif shows the peak is somewhere else now at
least in some cases.
attributes. These are defined in the standard sysfs interface for quite
some time, and at least three drivers (max6650, lm63 and applesmc)
implement them so we should support them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6029 7894878c-1315-0410-8ee3-d5d059ff63e0
representation of chip names.
sensord, sensors: Fix a memory leak when one or more chip names are
provided on the command line.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5740 7894878c-1315-0410-8ee3-d5d059ff63e0
use it to retrieve a specific subfeature by type. While it is slighly
less efficient than looping over sensors_get_all_subfeatures(), it
often makes the application code much more elegant.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4846 7894878c-1315-0410-8ee3-d5d059ff63e0
for faster main features lookup. One side effect of this change is
that subfeatures can no longer have labels nor be ignored. I do not
think that this is a problem in practice, and actually this makes a
lot of sense.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4834 7894878c-1315-0410-8ee3-d5d059ff63e0
get the list of all main features, and one to get the list of all the
subfeatures of a given main feature. This is a more logical interface for
applications to use. The current implementation is admittedly less than
optimal, because the storage structures weren't meant for it, but this
issue can (and will) be addressed later.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4831 7894878c-1315-0410-8ee3-d5d059ff63e0
standard sysfs interface. I don't think it makes much sense to
display the offset values as part of the output of "sensors" (it
would even probably confuse people) but having support for these
in libsensors makes it possible to adjust the offsets in
sensors.conf, which is convenient.
This closes ticket #2248.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4769 7894878c-1315-0410-8ee3-d5d059ff63e0
to add more "standard" feature types such as current or power,
we want to give them numbers that immediately follow the fan, voltage
and temperature features, so that the code is as simple as possible.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4767 7894878c-1315-0410-8ee3-d5d059ff63e0
feature number as the logical mapping. This means that the compute
mapping can be turned into a simple boolean flag. Doing so makes
struct sensors_feature_data smaller, which saves some memory (about
17 kB in my tests.)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4758 7894878c-1315-0410-8ee3-d5d059ff63e0
Ondřej Lysoněk