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. > - 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. One of the promises of udev was that Mesa would be able to ship some config files that attached our drivers' names to devices, so that udev could answer "what DRI driver do I open for this fd?" in one central way, rather than having Mesa's loader and X's loader both trying to do replicate the same behavior. We haven't made use of that, though, and it seems less important now that X doesn't do the loader thing (now our only loader variation is trying to handle old DRI drivers with new libGL). > I do recall Kristian and Eric participating in this discussion before, > but the only thing I can find is along the lines of "linux distros > should be using libudev" :-( Honestly, I'm leaning toward "let's just use the sysfs path and drop libudev" -- the sysfs code exists, and I think we've got more code complexity (and time wasted) dealing with the fallout from libudev screwing up their ABI, compared to just using Gary's open-coded stuff.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
