its prototype to suit our needs better.
* Pass the chip name by address.
* Pass the feature directly rather than its number.
* Switch to a sane convention for the returned value.
* Don't check for errors that can't happen.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4646 7894878c-1315-0410-8ee3-d5d059ff63e0
delegating the task to the user applications.
For now, I am calling sensors_get_ignored() in
sensors_get_all_features(), because this is the least intrusive way.
This is in no way optimal though, it would be better to not add
ignored features to the feature list in the first place. However,
doing so would require that the configuration file is read before
sysfs is scanned for features, which isn't currently the case. So
this improvement is left for later.
Note that this patch adds a small cost in terms of performance. This
is because we now honor ignore statements on all features (main ones
and subfeatures) while in practice "sensors" was only checking for
main features. It would be trivial to stop checking for subfeatures,
but it seems to me that supporting ignore on subfeatures is a good
move, as the user may actually want to ignore a specific subfeature.
Individual alarms come to mind. This will also be handy to debug the
generic print code in "sensors".
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4644 7894878c-1315-0410-8ee3-d5d059ff63e0
immediately follow their main feature. This makes it possible to simplify
sensors_get_all_features() quite a bit. We no longer need to maintain
separate pointers for the last main feature and the last subfeature,
we can simply walk the list linearly.
Note that I am still not entirely happy with this API. It was obviously
designed for debugging purposes (sensors -u) and without performance
concernes nor interface cleanliness in mind. I believe that we want to
tag main features and subfeatures as such, and let the application ask
specifically for the list of main features, and for each feature, for
its list of subfeatures (i.e. two functions instead of one.)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4643 7894878c-1315-0410-8ee3-d5d059ff63e0
* We no longer support any single type, so no need to handle this case.
* We can start looking for "_" at offset 3 rather than the beginning
of the string (the shortest valid prefix is "in0", 3 characters.)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4631 7894878c-1315-0410-8ee3-d5d059ff63e0
adjust it to fit our needs better:
* Call sensors_feature_get_type() before allocating memory for the
feature name. The allocation will be reverted for all sysfs files
which are not valid libsensors attributes, and there can be a lot
of these. So this saves a few memory allocations. But this means
that we want to pass a simple string to sensors_feature_get_type()
rather than a struct sensors_feature_data. This also means that
sensors_feature_get_type() gets the raw attribute name ("_input"
not stripped.)
* Get the channel number from sensors_feature_get_type() too. We
get it for free from sscanf(), so it's more efficient to return it
than to parse it again in sensors_read_dynamic_chip().
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4630 7894878c-1315-0410-8ee3-d5d059ff63e0
first called during the library initialization to generate the feature
tables. Then it is called again by sensors itself. This is because we
do not store the result the first time. I propose that we add a type
field to struct sensors_feature_data, where libsensors would store
the result of sensors_feature_get_type(). That way, the application
can get the information without calling sensors_feature_get_type()
again.
This change has the following benefits:
* Obviously, a small speed-up.
* sensors_feature_get_type() can be removed from the public interface.
This means that we can turn it into something that fits the
libsensors needs better, allowing for more optimizations (see next
patches.)
Note: the patch looks bigger that it really is, because I had to move
definitions around in sensors.h.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4629 7894878c-1315-0410-8ee3-d5d059ff63e0
and sensors_chip_features_list arrays tend to track the same information.
So it's much more simple, and more efficient, to have a single array. I
decided to keep sensors_proc_chips, because it already has memory management
helpers. One nice side effect is that the arbitrary limit to the number of
supported chips is now gone. Another one is that some of the memory leaks
were fixed.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4510 7894878c-1315-0410-8ee3-d5d059ff63e0
sensors_chip_features_list[]. Using only the prefix (as was done before)
makes it impossible to properly support multiple chips with the same prefix
but a different feature set.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4508 7894878c-1315-0410-8ee3-d5d059ff63e0
it possible to install both the old and the new libsensors and sensors,
making testing much easier. sensors3 will be renamed back to sensors before
we release.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4461 7894878c-1315-0410-8ee3-d5d059ff63e0
* Fix the handling of temperature hysteresis. Hysteresis is not a
temperature limit by itself, but a property of temperature limit.
* Handle per-limit temperature alarms.
With these fixes, the ADM1032 is properly supported by the new code.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4423 7894878c-1315-0410-8ee3-d5d059ff63e0
identify sysfs entries. Reasons for this rewrite / bugs fixed:
-Don't give features like alarms / sensor type / fault flag a
compute mapping only a normal mapping
-Don't generate features for sysfs entries like uvent, modalias, etc.
instead only generate features for features known by
sensors_feature_get_type()
-Sort the list of found features logically instead of sorted in alphabet order
of the sysfs entry. So now it starts with all in entries, then all fan and
then all temp. Just like the order of most entries in lib/chips.c. Also
this means that it now contains in0 - in10 in that order and not in0, in10,
in1 - in9
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4368 7894878c-1315-0410-8ee3-d5d059ff63e0
abituguru seems to work well with the new dynamic chip support and generic
chip printroutines. note: the abituguru code should be completly removed in
the future.
-comment k8temp entry in lib/chips.c and prog/sensors/main.c, as the
k8temp seems to work well with the new dynamic chip support and generic
chip printroutines. note: the k8temp code should be completly removed in
the future.
-make the match for the subtype exact instead of a strncmp, otherwise
an alarm_enable flag gets classified as an alarm, leading to all sensors who
have their alarm enabled getting an alarm reported, as the alarm_enabled gets
read as alarm.
-and do the same for the _input match to check if this is a main or subfeature
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4367 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare