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
* We don't need to compute the mapping during the first pass: this
field is overwritten when renumbering the features anyway.
* Only main features have features mapping to them.
* Only subfeatures have mappings, so we can stop the scan at the next
main feature.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4763 7894878c-1315-0410-8ee3-d5d059ff63e0
from its type, there's no need to store this scaling factor. We can
instead compute it at runtime. This saves some memory (about 10 kB
in my real-world test), and the runtime overhead is totally
negligible.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4762 7894878c-1315-0410-8ee3-d5d059ff63e0
idea is to have separate indexing for subfeatures with a compute
mapping and for subfeatures without it. They still follow each
other in the big table but this avoids wasting memory due to the
numbering gap between them.
This cuts the amount of memory (temporarily) allocated by
sensors_read_dynamic_chip() almost by half, and also speeds it up
a little as it now takes less iterations to walk the sparse array.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4761 7894878c-1315-0410-8ee3-d5d059ff63e0
position N in the array. This allows for O(1) look-ups, as opposed
to O(N) before. This makes sensors_lookup_feature_nr() 2.4 times
faster in my real-world tests, resulting in a 6% performance boost
on average in the runtime part of "sensors".
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4759 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
we need to add "_input" to get the correct sysfs file name. This is
much faster. This is still a ugly hack I'd like to get rid of, but at
least now the slowdown is acceptable.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4743 7894878c-1315-0410-8ee3-d5d059ff63e0
sensors_bus_id. This prevents wasting space with padding on 64-bit
systems, saving some memory (128 bytes for sensors_bus_id, nothing
yet for sensors_feature_data but it will come later).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4733 7894878c-1315-0410-8ee3-d5d059ff63e0
MAX_SUB_FEATURES in the process.) This value could change in the
future so it's not safe to make it part of the libsensors API.
And it isn't needed either, applications shouldn't need to use
this value.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4732 7894878c-1315-0410-8ee3-d5d059ff63e0
caller select which subset of chips it wants. This is slightly better
size-wise than letting all applications do the filtering by themselves.
This will change the way the command line parameters of "sensors" are
interpreted. Beforehand, the chips were always returned in the order
in which they were listed by the library. Also, each chip could be listed
only once. From now on, the chips will be listed in the order in which
they are passed on the command line, which I think makes more sense. A
side effect is that chips can be listed more than once, if that's what
the user asks for. Not very useful though.
This change makes it possible to make sensors_match_chip() internal
to the library. Filtering the list of chips returned by
sensors_get_detected_chips() was the last known external use for this
function.
This patch looks much bigger than it really is, but the largest part is
really only code reindentation.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4701 7894878c-1315-0410-8ee3-d5d059ff63e0
Instead, the application will have to call sensors_exit() explicitly
before calling sensors_init() again. Most applications don't offer
any way to reload the configuration file, so better optimize for the
initial load.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4693 7894878c-1315-0410-8ee3-d5d059ff63e0
SPI bus statements in the configuration file are not yet supported, as
SPI buses don't have a name attribute yet, it's not possible to identify
them and thus no substitution is possible.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4689 7894878c-1315-0410-8ee3-d5d059ff63e0
i2c-centric. Make it more neutral so that we can cleanly support
additional bus types such as SPI or One-Wire.
This second part updates sensors_bus to use sensors_bus_id. Thanks
to Mark M. Hoffman for showing me how the configuration file
parser could be modified to support that change.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4687 7894878c-1315-0410-8ee3-d5d059ff63e0
i2c-centric. Make it more neutral so that we can cleanly support
additional bus types such as SPI or One-Wire.
This first part introduces sensors_bus_id, and updates
sensors_chip_name to use it.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4686 7894878c-1315-0410-8ee3-d5d059ff63e0
rewrite sensors_parse_chip_name() with a simpler algorithm. The new
code is smaller by about one third, and twice as fast on average
(5 times as fast in the most frequent case "foo-*".)
This closes ticket #2221.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4677 7894878c-1315-0410-8ee3-d5d059ff63e0
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
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
Jean Delvare