[PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2

[Jonathan Gray]

On Tue, Jun 26, 2018 at 11:38:20AM +0100, Emil Velikov wrote:
> On 21 June 2018 at 16:32, Jonathan Gray <jsg at jsg.id.au> wrote:
> > On Thu, Jun 21, 2018 at 03:24:49PM +0100, Emil Velikov wrote:
> >> Hi Jonathan,
> >>
> >> On 1 December 2016 at 04:18, Jonathan Gray <jsg at jsg.id.au> wrote:
> >>
> >> > --- a/xf86drm.c
> >> > +++ b/xf86drm.c
> >> > @@ -3248,6 +3248,67 @@ drm_device_validate_flags(uint32_t flags)
> >> >   */
> >> >  int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device)
> >> >  {
> >> > +#ifdef __OpenBSD__
> >> > +    /*
> >> > +     * DRI device nodes on OpenBSD are not in their own directory, they reside
> >> > +     * in /dev along with a large number of statically generated /dev nodes.
> >> > +     * Avoid stat'ing all of /dev needlessly by implementing this custom path.
> >> > +     */
> >> I was in the area, fixing the odd bug and doing some cleanups and a
> >> question came to mind:
> >>
> >> Is there some obstacle of placing the drm nodes under /dev/dri/? It
> >> would involve a check/update through the OpenBSD tree, yet no obvious
> >> downsides comes to mind.
> >> I think it would make things more distinct and obvious. IIRC the
> >> OpenBSD xserver does some checking which /dev node opened, the
> >> suggestion should help there.
> >>
> >> What do you think?
> >> Emil
> >
> > There are no other devices under a sub-directory besides /dev/fd/.
> > I don't think anyone is going to be onboard with changing things for
> > drm nodes.  Though drm device nodes names will have to be revisted
> > when/if render nodes etc get supported.  drmR drmC etc have not
> > been proposed yet.
> 
> I see, that's enlighening.
> 
> Out of curiosity: personally, do you see any technical issues with a
> sub-directory approach?

I get that you want a single path but it seems these functions were
really designed assuming the approach was going to be a sub-directory.