[lm-sensors] libsensors API changes

[Jean Delvare <khali@linux-fr.org>]

Hi all,

In the past few days, I have been thinking about the libsensors4 API,
in particular the way the chip features are accessed. Right now we have
a single function, sensors_get_all_features(), returning all features
in sequence, mixing main features and subfeatures. Actually, main
features and subfeatures are only differentiated by the mapping field
value, but otherwise they are represented by the same structure.

Looking at the code of several user-space applications using
libsensors, this interface is not very convenient. Except for "sensors
-u", which makes some sense as I think it is the reason why this
interface exists in the first place. Here is a list of things I found
the applications would take benefit of if libsensors would propose a
suitable interface:

* Separate lists for main features and subfeatures of each main feature.

* Subfeature existence information (does feature F of chip C have
subfeature X?)

* Direct subfeature value lookup (what's the value of subfeature X of
feature F of chip C?)

So I am in the process of extending the libsensors4 API to implement
these interfaces. The first point can be either done easily (simply
splitting sensors_get_all_features() to two separate functions) or
taken further: I think it would make sense to have a separate structure
for main features or "channels" (e.g. in0, temp1...) and for
subfeatures (e.g. in0_input, temp1_min...) This would make things much
more structured. For example, labels essentially apply to main
features, not subfeatures. Same goes for compute statements. OTOH, set
statements apply to subfeatures, not main features.

Going that route would speed up the library code at some places. It
would also let us clear the fooN / fooN_input confusion which forces us
to have some ugly hard-coded exceptions in the library. The drawback is
that we may lose some flexibility by going that route, so I'm not sure
how far we want to go.

The last two points would avoid some duplication in applications, and
would make their code look much nicer. There is a concern with
algorithmic complexity though: direct value lookups are likely to be in
O(N) while for example "sensors" manages to do it in O(1) at the
moment. However, the number of subfeatures being relatively small for
each main feature, it might not be an issue at all.

I am working on some patches implementing these API changes, I hope to
be able to post them for comments and review at the end of the week.
Until then, I would also welcome comments on the general ideas I just
exposed.

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors