On 8 July 2015 at 18:35, Eric Anholt <e...@anholt.net> wrote: > Emil Velikov <emil.l.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
