[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220228110351.20518-1-nicolas.cavallari@green-communications.fr>
Date: Mon, 28 Feb 2022 12:03:50 +0100
From: Nicolas Cavallari <nicolas.cavallari@...en-communications.fr>
To: "Rafael J. Wysocki" <rafael@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Amit Kucheria <amitk@...nel.org>,
Zhang Rui <rui.zhang@...el.com>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Testing the thermal genetlink API
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.
Powered by blists - more mailing lists