On Fri, 14 Jul 2023 at 11:32, Simon Ser <cont...@emersion.fr> wrote:
>
> (cc Daniel Vetter and Pekka because this change has uAPI repercussions)
>
> On Friday, June 30th, 2023 at 13:56, James Zhu <james....@amd.com> wrote:
>
> > From: Christian König <ckoenig.leichtzumer...@gmail.com>
> >
> > This makes room for up to 128 DRM devices.
> >
> > Signed-off-by: Christian König <christian.koe...@amd.com>
> > Signed-off-by: James Zhu <james....@amd.com>
> > ---
> > drivers/gpu/drm/drm_drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 73b845a75d52..0d55c64444f5 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -137,7 +137,7 @@ static int drm_minor_alloc(struct drm_device *dev,
> > unsigned int type)
> > r = idr_alloc(&drm_minors_idr,
> > NULL,
> > 64 * type,
> > - 64 * (type + 1),
> > + 64 * (type + 2),
>
> The type comes from this enum:
>
> enum drm_minor_type {
> DRM_MINOR_PRIMARY,
> DRM_MINOR_CONTROL,
> DRM_MINOR_RENDER,
> DRM_MINOR_ACCEL = 32,
> };
>
> Before this patch, 0..63 are for primary, 64..127 are for control (never
> exposed by the kernel), 128..191 are for render, 2048..2112 are for accel.
> After this patch, 0..127 are for primary, 64..191 are for control (never
> exposed by the kernel), 128..255 are for render, 2048..2176 are for accel.
>
> I'm worried what might happen with old user-space, especially old libdrm.
I also share the same concern. Although the bigger issue is not libdrm
- since we can update it and prod distributions to update it.
The biggest concern is software that cannot be rebuild/updated -
closed source and various open-source that has been abandoned.
As mentioned in the gitlab ticket - the current style of embedding the
uABI/uAPI in each and every application is not great IMHO. That is why
I've introduced the `drmGetDevices2` API, to consolidate most of the
chaos in a single place.
For going forward, here is one way we can shave this yak:
- update libdrm to max 64 nodes
- roll libdrm release, nag distributions to update to it // could be
folded with the next release below
- update libdrm to use name driven type detection
- roll libdrm release, nag distributions to update to it
- once ^^ release hits most distributions, merge the above proposed
kernel patch
- the commit message should explain the caveats and fixed libdrm version
- we should be prepared to revert the commit, if it causes user
space regression - fix (see below) and re-introduce the kernel patch
1-2 releases later
In parallel to all the above, as a community we should collectively
audit and update open-source applications to the `drmDevices2` API.
As with other legacy (DRI1), this one will take some time but we can get there.
HTH
Emil
