On Saturday, 15 October 2016, Jonathan Gray <j...@jsg.id.au> wrote: > On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote: > > From: Emil Velikov <emil.veli...@collabora.com <javascript:;>> > > > > Currently mesa has three code paths in the loader - libudev, manual > > sysfs and drm ioctl one. > > > > Considering the issues we had with libudev - strip those down in favour > > of the libdrm drm device API. The latter can be implemented in any way > > depending on the platform and can be reused by others. > > > > Cc: Jonathan Gray <j...@jsg.id.au <javascript:;>> > > Cc: Jean-S??bastien P??dron <dumbb...@freebsd.org> > > Signed-off-by: Emil Velikov <emil.veli...@collabora.com <javascript:;>> > > --- > > Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD > > implementation of the drm*Device API a while back. With this commit > > you'll be 'forced' to prep some ;-) > > It has been a while since I looked into that. The design seemed to > assume that the user running code that called into libdrm had the > ability to enumerate pci busses. > > On OpenBSD /dev/pci* is only read/writable by root. /dev/drm* is > chowned after a user logs into a console. > > Yes that's correct. The principle is that the platform/kernel has a method of enumerating and providing basic information for the available devices. Note that there are multiple applications explicitly dropping OpenBSD support from their TODO because it lacks the ability [from unprivileged context].
We don't use filesystems for communicating with the kernel like linux > does so ioctls are really the best fit. The loader parts used at the > moment use drm driver specific ioctls, hopefully a generic version of > those that can return the vid/pid, subids and function id numbers would > cover most of it. Afaict retrieving the vendor/device ID et al is not a security concern (admittedly I'm not a security person) nor drm specific. As-is one will end up with multiple implementations - one per subsystem leading to extra code and maintenance burden on both OpenBSD end and for apps who want to support the platform. Hope that makes things clear and doesn't sound too ranty ;-) Emil
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
