introduced when getting rid of the i2cdetect dependency. I had
forgotten that i2c-isa was not listed in class i2c-dev but was
still listed in class i2c-adapter.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4650 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
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
if we discard them later, their presence in the list can prevent the
"no sensors found" event from triggering. It also causes the script to
suggest loading i2c bus drivers which are not needed for hardware
monitoring.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4610 7894878c-1315-0410-8ee3-d5d059ff63e0
2.6 kernel-based systems, for others they should have been created at
system installation time. If they are missing, sensors-detect will run
MAKEDEV to create them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4593 7894878c-1315-0410-8ee3-d5d059ff63e0
bash implementation was spawning too many child processes, and that
was true, but this has been addressed since. And I don't particularly
enjoy maintaining two scripts doing exactly the same thing.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4590 7894878c-1315-0410-8ee3-d5d059ff63e0
This is simpler and will work better in most cases. For example this
should address at least part of ticket #2224. It seems that quadratic
was used to lower the average noise level, but I don't think this is a
valid reason. The new MINPWM and MAXPWM parameters will also let the
user control the noise level if really needed.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4589 7894878c-1315-0410-8ee3-d5d059ff63e0
(in particular SPD and EDID EEPROMS) at addresses where hardware monitoring
chips are known to live, to prevent misdetections, but we no longer point
the user to drivers for these chips.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4529 7894878c-1315-0410-8ee3-d5d059ff63e0
