Messages in this thread | | | Date | Thu, 27 Jul 2023 14:01:08 +0200 | Subject | Re: [PATCH v6 3/4] drm: Expand max DRM device number to full MINORBITS | From | Christian König <> |
| |
Am 26.07.23 um 20:15 schrieb Simon Ser: > On Monday, July 24th, 2023 at 23:14, Michał Winiarski <michal.winiarski@intel.com> 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.
| |