lkml.org 
[lkml]   [2022]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectTesting the thermal genetlink API
Date
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.


\
 
 \ /
  Last update: 2022-02-28 12:15    [W:0.063 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site