[RFC 0/1] DRM Node Probing functionality

[Tomasz Figa]

Hi Rob,

On Thu, Apr 12, 2018 at 12:56 PM Robert Foss <robert.foss at collabora.com>
wrote:

> *Resend the whole actual series*

> This patch implements a simple function for matching DRM device FDs
against
> the desired properties of a device that you are looking for.

> The properties that are possible to look for are the elements of
DrmVersion
> and DrmDevice.

> The discussion that led to this series can be found here:
> https://lists.freedesktop.org/archives/mesa-dev/2018-January/183878.html

> In the previous discussion we left off having settled on implementing this
> in mesa/src/loader/loader.c, which I initially did. But the code ended up
being
> so generic that there's no reason for it not to live in libdrm, since it
can be
> used for any compositor and mesa.

> The implementer will still have to iterate through all of the devices
available
> on the target, and see if they match. This additional functionality could
be
> moved into libdrm at a later point if it turns out that all of the users
do this
> in the same manner.
> If there is some variety, for example with selecting fallback devices if
nothing
> matches maybe it is best left up to the user of libdrm.

> The biggest problem with the approach as implemented, the way I see it,
is how
> we match against the DrmVersion/DrmDevice of a given FD.
> Currently we use DrmVersion & DrmDevice as supplied by the caller to
define what
> we are looking for.
> This is a little bit problematic, especially for DrmDevice, since all of
the
> elements of the struct do not have enough bitspace to signal that we are
> uninterested in looking for that specific element. DrmDevice uses
> drmDevicesEqual() to do what amounts to a memcmp of the DrmDevice
argument and
> the one of the FD. So looking for any device on any PCI bus with just the
> PCI vendor ID supplied isn't possible.

> An alternative Daniel Stone suggested is adding enums for different
properties
> and allowing the caller to supply a list of properties that are
interesting and
> their values. In terms of long-term maintainership this might be less
pleasant
> than the  approach of the current implementation.

I'm personally okay with how patch 1 implements the matching. Thanks for
this work. Looking forward to the Mesa probing helper, which uses this! :)

P.S. I normally use my @chromium.org email for mailing lists.

Best regards,
Tomasz