Messages in this thread | | | From | Nicolas Cavallari <> | Subject | Testing the thermal genetlink API | Date | Mon, 28 Feb 2022 12:03:50 +0100 |
| |
I've played a bit with the thermal netlink interface and it wasn't pleasant:
1. The way attributes are used is painful. Instead of using arrays of nested structs-like, it flattens them into a big nested attr where you have to guess when an entry starts and when it ends. libnl provides no helper for this case:
[{nla_type=TZ|F_NESTED}, [{nla_type=TZ_ID}, 1] [{nla_type=TZ_NAME}, "name1"] [{nla_type=TZ_ID}, 2] [{nla_type=TZ_NAME}, "name2"] [{nla_type=TZ_ID}, 3] [{nla_type=TZ_NAME}, "name3"] [{nla_type=TZ_ID}, 4] [{nla_type=TZ_NAME}, "name4"] ]
2. The genl_cmd types are not unique between multicast events and command replies. If you send genl_cmd=3 (CMD_TZ_GET_TEMP) and you get a genl_cmd=3 reply, you cannot know if it is a CMD_TZ_GET_TEMP response or a EVENT_TZ_DISABLE because both have genl_cmd=3, but completely different semantics.
3. The API is heavy. Getting the complete information about all thermal zones requires 1 + 6 * thermal_zones netlink requests, each of them only returning few information. You need most of them to merely translate the event's TZ_ID/TZ_TRIP_ID/CDEV_ID to names.
4. THERMAL_GENL_CMD_TZ_GET_TRIP cause an oops if the thermal zone driver does not have a get_trip_hyst callback. This concerns all drivers, short of two. A patch follows.
For the record, I couldn't find any open source program using this API. It's also not enabled in all distributions.
| |