On Saturday, 15 October 2016, Jonathan Gray <<a href="mailto:jsg@jsg.id.au">jsg@jsg.id.au</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote:<br>
> From: Emil Velikov <<a href="javascript:;" onclick="_e(event, 'cvml', 'emil.velikov@collabora.com')">emil.velikov@collabora.com</a>><br>
><br>
> Currently mesa has three code paths in the loader - libudev, manual<br>
> sysfs and drm ioctl one.<br>
><br>
> Considering the issues we had with libudev - strip those down in favour<br>
> of the libdrm drm device API. The latter can be implemented in any way<br>
> depending on the platform and can be reused by others.<br>
><br>
> Cc: Jonathan Gray <<a href="javascript:;" onclick="_e(event, 'cvml', 'jsg@jsg.id.au')">jsg@jsg.id.au</a>><br>
> Cc: Jean-S??bastien P??dron <dumbbell@FreeBSD.org><br>
> Signed-off-by: Emil Velikov <<a href="javascript:;" onclick="_e(event, 'cvml', 'emil.velikov@collabora.com')">emil.velikov@collabora.com</a>><br>
> ---<br>
> Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD<br>
> implementation of the drm*Device API a while back. With this commit<br>
> you'll be 'forced' to prep some ;-)<br>
<br>
It has been a while since I looked into that.  The design seemed to<br>
assume that the user running code that called into libdrm had the<br>
ability to enumerate pci busses.<br>
<br>
On OpenBSD /dev/pci* is only read/writable by root.  /dev/drm* is<br>
chowned after a user logs into a console.<br>
<br></blockquote><div>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].<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We don't use filesystems for communicating with the kernel like linux<br>
does so ioctls are really the best fit.  The loader parts used at the<br>
moment use drm driver specific ioctls, hopefully a generic version of<br>
those that can return the vid/pid, subids and function id numbers would<br>
cover most of it. </blockquote><div>Afaict retrieving the vendor/device ID et al is not a security concern (admittedly I'm not a security person) nor drm specific.</div><div><br></div><div>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.</div><div><br></div><div>Hope that makes things clear and doesn't sound too ranty ;-)</div><div>Emil</div>