sensors_parse_chip_name(). sensors_snprintf_chip_name() converts
a chip name from its internal representation to a human readable
string. So far, each user program had to reimplement this function.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4676 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
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
Some basic support, in the form of sensors_get_all_features(), for chips that
are known to the library, but unknown to the application. prog/sensors has
a demo of how to use this, in function print_unknown_chip in chips.c.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@110 7894878c-1315-0410-8ee3-d5d059ff63e0
This brings the archive into synch with my harddisk...
Everything in the lib directory should compile without problems (yes, even
without warnings even if WARN=1). It is not well-tested, though, and there
are some minor functions which must still be added. It is now almost
usable.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@95 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare