class device directory rather than directly in the device directory.
The latter is what all drivers do at the moment, but in the long run
the former is preferred as it prevents attribute name collisions.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5093 7894878c-1315-0410-8ee3-d5d059ff63e0
guessing it from how the device identifier looks like. For kernels
<= 2.6.17, we use the bus symlink instead. For kernels <= 2.6.11,
neither symlink exist so we fallback to the old type guessing
approach. It doesn't really matter as all hwmon devices were
i2c devices back then.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5092 7894878c-1315-0410-8ee3-d5d059ff63e0
Instead, access sysfs directly, using 3 embedded helper
functions. My motivations for doing this are:
* As far as I know, libsysfs is no longer maintained.
* libsysfs does much more than we need. For example, when asking for a
device attribute list, libsysfs will read the contents and permissions
of all attributes. Not only does this waste CPU cycles per se, but in
the case of hwmon driver it also triggers register reads, which can be
slow for SMBus chips.
* libsysfs enforces the difference between devices and class devices,
while future changes will be easier if we can handle both types alike.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5067 7894878c-1315-0410-8ee3-d5d059ff63e0
be found, fallback to /etc/sensors.conf. This allows for an old
libsensors and a new libsensors to be installed in parallel, and each
one has its own configuration file.
One important change here is that the default configuration file will
be installed as /etc/sensors3.conf by "make install".
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4990 7894878c-1315-0410-8ee3-d5d059ff63e0
simply ignore the errors. In debug mode, call sensors_fatal_error().
As a side note, there is certainly room for improvement in the way
errors are reported by libsensors. sensors_fatal_error() is fatal,
and sensors_parse_error() is too specific, so we lack a more general
error reporting function. printf-like formatting for error messages
would also be a good idea.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4855 7894878c-1315-0410-8ee3-d5d059ff63e0
Rename SENSORS_ERR_PROC to the more neutral SENSORS_ERR_KERNEL.
Introduce SENSORS_ERR_NO_DEVS for finer-grained error reporting.
Use SENSORS_ERR_KERNEL and SENSORS_ERR_NO_DEVS where appropriate.
No error message for invalid error codes.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4854 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
chip in the detected chip list. It is more efficient to do it once
and for all than to do it over and over again in
sensors_lookup_feature_nr() and sensors_lookup_subfeature_nr() as
was done before.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4843 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