libsensors API: review

[khali]

We must review the libsensors API before we release lm-sensors 3.0.0. This will be a new libsensors .so version, let's get it right now as we won't be allowed to change it afterwards.

Things in particular which I think need investigation:

• Is sensors_get_ignored() useful? Looks to me like ignored features should not be listed by libsensors in the first place. In other words, I think that the handling of ignored features should be moved from user programs to libsensors itself.
• Same question for sensors_match_chip(). I'm surprised it's not internal only.
• SENSORS_FEATURE_MAX_SUB_FEATURES should not be part of the interface. It is likely to change in the future. Instead, we either need to export a function returning this value, or change the interface so that the user no longer needs to care about this value.
• sensors_get_adapter_name() assumes that all adapters are I2C adapters. That's not correct, we start seeing sensors on SPI buses, and of course there are also LPC and PCI-based hardware monitoring chips. struct sensors_chip_name has the same problem.
• Not sure why sensors_chip_name_has_wildcards() is public. It's not used in sensors nor sensord, and I don't see how it could be useful outside of libsensors.

These are only starting points after a quick look, maybe some of my points are not correct, and maybe other things need to be changed.

[khali]

sensors_feature_get_type() is no longer part of the API (r4629).

[khali]

sensors_get_ignored() is no longer part of the API (r4644).

[khali]

sensors_chip_name_has_wildcards() is no longer part of the API (r4647).

sensors_do_all_sets() is no longer part of the API (r4648).

[khali]

API review completed. I've adjusted the API to be more convenient to use by applications. In particular, sensors_get_all_features() was split into two separate functions (sensors_get_features() and sensors_get_all_subfeatures()) in r4831, and sensors_get_subfeature() was added in r4846.