[Mesa-dev] [RFC] loader: libudev vs sysfs vs libdrm

[Emil Velikov]

On 8 July 2015 at 18:35, Eric Anholt <eric at anholt.net> wrote:
> Emil Velikov <emil.l.velikov at gmail.com> writes:
>
>> Hello all,
>>
>> A recent patch by Chris, fixing some libudev fun in our loader, made
>> me think if we can clear it up a bit.
>>
>> Having three different ways of retrieving the vendor/device ID does
>> feel a bit excessive. Plus as one gets fixed others are likely to
>> break - and they do.
>> So here is a summary of each method, from portability POV.
>>  - libudev: widely common across Linux distributions (but not all).
>>  - sysfs: written by Gary Wong to target GNU Hurd and *BSD. The *BSD
>> folk never got to using it though :-\
>
> Huh?  There's no sysfs on BSD.  I actually don't see a reason for this
> path to exist, unless we wanted to drop libudev entirely.  We should
> pick one of these two, certainly.
>
There seems to be a libudev equivalent (but not identical from our
POV) for *BSD as is some sysfs work. Don't think that either one is
baked enough atm.

>>  - libdrm: used as a last resource fall-back after the above two. the
>> sole option used by *BSD, MacOS and Android.
>>
>> libdrm seems like a nice middle ground that can be used everywhere.
>> Which begs the question: from a technical POV, is there any
>> advantage/disadvantage of using one over the other ?
>
> This "use the kernel driver name" thing is a bad hack, without some
> mapping in userspace from kernel driver name to userspace driver name.
> It's a hack that non-pci are relying on so far, though.
>
Knowing how Winbooze has handled this policy, I agree with you here.

Yet something is amiss. Am I reading the code correctly or are the
three methods are for retrieving the vendor/device ID? The kernel
driver name does not (seem to) pay any role in determining the dri
module name. The mapping from device/vendor IDs the common code.

Thanks
Emil