[Mesa-dev] [RFC] loader: libudev vs sysfs vs libdrm
emil.l.velikov at gmail.com
Thu Jul 9 06:22:18 PDT 2015
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.
More information about the mesa-dev