[Mesa-dev] [PATCH] loader: add a libdrm case for loader_get_device_name_for_fd

[Jonathan Gray]

On Wed, Apr 20, 2016 at 01:33:24PM +0100, Emil Velikov wrote:
> On 20 April 2016 at 03:27, Jonathan Gray <jsg at jsg.id.au> wrote:
> > On Tue, Apr 19, 2016 at 07:00:18PM +0100, Emil Velikov wrote:
> >> On 19 April 2016 at 04:03, Jonathan Gray <jsg at jsg.id.au> wrote:
> >> > Any objections to this?
> >> >
> >> Absolutely none. I simply missed it.
> >>
> >> > On Mon, Dec 21, 2015 at 04:39:55PM +1100, Jonathan Gray wrote:
> >> >> Use dev_node_from_fd() with HAVE_LIBDRM to provide an implmentation
> >> >> of loader_get_device_name_for_fd() for non-linux systems that
> >> >> use libdrm but don't have udev or sysfs.
> >> >>
> >> >> Signed-off-by: Jonathan Gray <jsg at jsg.id.au>
> >> Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
> >>
> >> Jonathan, apart from the patches that I've replied to (and the llvm
> >> one in a second) do you have any more, even if they're
> >> nasty/subjective/etc. ? Please send them over and ping me/us is
> >> there's no reply within a week or so.
> >
> > Well some are things like disabling drirc so we can sandbox the chromium
> > process with a GL context which aren't really suitable.
> >
> Ahh yes - drirc workaround might not be applicable. Although others
> such as the "LLVM requirement and r300" (as described in another
> thread) are good. So please do send the lot and don't get (too)
> annoyed if some things get bikeshed(ed) to death. Hopefully that won't
> happen but you never know.

I don't think all are suitable, and some need to be reworked/generalised.

> 
> >>
> >> On the topic of the loader I hope you managed to take a look at the
> >> libdrm drmDevice API. It does (almost) the same thing as the below
> >> patch, but my goal is to keep it separate so that one can reuse it
> >> from other places, plus we can re-spin a libdrm release as often
> >> and/fast as we need to. In other words - most/all of this nasty code
> >> will get moved from mesa to libdrm. Note current libdrm implementation
> >> is Linux only. Please throw in a patch when you can spare some time.
> >
> > From a quick look:
> >
> > drmGetMinorNameForFD / /dev path matching fd
> >         drm_get_device_name_for_fd from mesa
> > drmParseSubsystemType / return fixed int for bus
> >         always return DRM_BUS_PCI
> > drmParsePciDeviceInfo / get pci vendorid/deviceid and subids
> >         drm_get_pci_id_for_fd from mesa
> >
> > drmParsePciBusInfo / get pci domain/bus/dev/func from only major/minor
> >
> > libpciaccess wouldn't work here, I suspect this would need a new drm
> > ioctl.  Would it be possible to somehow reserve an ioctl number on the
> > linux side that linux wouldn't need to use?
> Surely you have some way to get such (somewhat trivial) information
> from another userspace, right ? Pretty much anyone can/should be able
> to query the 'hardware location' of a device - aka lspci style. You
> guys must have that one.

Access to pci devices via /dev/pci* with pcidump(8) or lspci from
ports requires root.  It seems strange to want something that isn't
an ioctl when the function takes an open file descriptor to a drm
device as an argument.

> 
> Adding (DRM specific) IOCTLS is definitely not what we want here.
> 
> If any of the split and/or implementation does not work for you guys,
> feel free to scrap it and plug your own version.
> 
> Related: Who is responsible for creating the card/render/control/etc
> nodes as the hardware is detected (system goes up) ? Is it really
> libdrm or you guys have a some method (daemon?) that manages these
> kind of things. Why ? I'm really inclined on nuking the mknod and
> friends from libdrm. Hopefully in the near future.

We don't do render/control nodes yet but will in future.

The version of libdrm we have have in xenocara currently has a
#ifndef __OpenBSD__ around the mknod block.  So removing it wouldn't
cause any problems for us.

There is no daemon or vfs for dev entries.  The default device nodes
are platform specific, on amd64 it is currently /dev/drm0 -> /dev/drm3
with any additional entries created via the MAKEDEV script or mknod.