On Tue, Oct 11, 2022 at 01:55:01PM +0200, Christian König wrote:
> Am 11.10.22 um 13:39 schrieb Simon Ser:
> > On Tuesday, October 11th, 2022 at 13:04, Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote:
> >
> > > --- a/include/drm/drm_file.h
> > > +++ b/include/drm/drm_file.h
> > > @@ -54,7 +54,6 @@ struct file;
> > > */
> > > enum drm_minor_type {
> > > DRM_MINOR_PRIMARY,
> > > - DRM_MINOR_CONTROL,
> > > DRM_MINOR_RENDER,
> > > };
> > This makes me uncomfortable: this enum no longer matches DRM_NODE_* in
> > libdrm.
>
> Ah! There it was! I was remembering in the back of my head that we had
> somehow used this in libdrm as well, but couldn't really get where exactly.
>
> But I don't really see a problem here. The control nodes are identified by
> name and we don't expose them for quite some time now without any negative
> impact.
>
> Even the minor number distribution stays the same. So what bad can come from
> this?
>
> Thanks,
> Christian.
>
I proposed something similar in:
https://lore.kernel.org/dri-devel/20220817230600.272790-1-michal.winiarski@xxxxxxxxx/
except acompanied by expanding the minor pool to accomodate more than
128 devices:
And after receiving similar feedback, that eventually evolved into
leaving the "legacy minors" alone, and changing the rules only for cases
where we have more than 64 devices (when we run out of the "legacy
minors").
Perhaps something like this:
https://lore.kernel.org/dri-devel/20220911211443.581481-1-michal.winiarski@xxxxxxxxx/
Would work for your usecase as well?
-Michał
