Adding an API to reserve fixed numbers would work but:
* if the fixed numbers are chosen by the driver ("drm_reserve_id(u64_max
-1)"), I don't see the benefit over the current patch
* if the fixed numbers are allocated by drm (drm_reserve_id("vm_update") ->
u64), it would then require a way to expose them to userspace (through
/sys/kernel/debug/dri/x/clients?)
Yeah, both is possible, I'm fine with either.
The benefit is that this way it becomes an official API, which can (and must)
be considered should there ever be a change on drm_file::client_id.
If someone would patch drm_file::client_id to start allocating IDs from high to
low, your corresponding driver code would silently break, because it relies on
an implementation detail of something that is not an official API.
Yes, I know that this exact case won't happen, but I guess you get the idea. :-)
After looking a bit more into this, I came to the conclusion that IMO the 2
above options aren't great:
* the first adds a function that expose the possibility of reserving an id so we'll have to keep
track of such reserved ids for a benefit that is limited at best
* the second option is nicer on the surface because it doesn't make the tools dependent on
hard-coded kernel ids. But it also requires quite a bit of changes and memory usage allocations.
Honestly I'm wondering if adding a comment to drm_file_alloc like this would be
enough;
/* Get a unique identifier for fdinfo.
* The highest ids may be used by drivers for tracing purposes. Overlapping
is
* unlikely to occur, and if it does the impact will be limited to tracing.
*/
file->client_id = atomic64_inc_return(&ident);
What do you think?
Pierre-Eric
