Am 26.07.23 um 20:15 schrieb Simon Ser:
On Monday, July 24th, 2023 at 23:14, Michał Winiarski <michal.winiarski@xxxxxxxxx> wrote:
Having a limit of 64 DRM devices is not good enough for modern world
where we have multi-GPU servers, SR-IOV virtual functions and virtual
devices used for testing.
Let's utilize full minor range for DRM devices.
To avoid regressing the existing userspace, we're still maintaining the
numbering scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.
In general the approach looks good to me. Old libdrm will see the new
nodes as nodes with an unknown type when it tries to infer the nod type
from the minor, which is as good as it gets.
Yeah, agree. I wouldn't upstream patch #4, but apart from that it looks
like it shouldn't break anything which wasn't broken before.
We do need patches to stop trying to infer the node type from the minor
in libdrm, though. Emil has suggested using sysfs, which we already do
in a few places in libdrm.
That sounds like a really good idea to me as well.
But what do we do with DRM_MAX_MINOR? Change it or keep it and say apps
should use drmGetDevices2() like Emil suggested?
Regards,
Christian.
