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

[Mark Kettenis]

> Date: Tue, 26 Jun 2018 20:58:18 +1000
> From: Jonathan Gray <jsg at jsg.id.au>
> 
> 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.

The bigger picture here is that this code is primarily used to query
for information about an open drm file descriptor.  The Linux
implementation does a lot of filesystem groveling to achieve that.
Especially the bits that descend into /sys are never going to work on
OpenBSD.  If a more OS-agnostic approach is wanted, I would say an
ioctl to return the relevant information would be more appropriate.
This is actually what we did for OpenBSD where we implemented
DRM_IOCTL_GET_PCIINFO to implement drmParsePciBusInfo.  Such an
approach avoids the issue of mapping the file descriptor back to a
file system path.  Also note that mapping and open file descriptor to
a file system path is fundamentally impossible on Unix without
cheating.  Although cheating is fairly easy for devices.

If mapping a file descriptor back to a filesystem path is necessary,
OpenBSD actually implements devname(3) which uses a database to map
device major/minor pairs back to a device name.  This is actually a
function that was introduced in 4.4BSD, and as far as I can tell it is
still present in FreeBSD and NetBSD as well.  We could change the
OpenBSD implementation of drmGetDevice2() to use that, but it wouldn't
really make the code simpler.

All in all, I think it is best to keep the Linux and OpenBSD code
separate here.