On Sat, Dec 14, 2013 at 3:33 AM, Kenneth Graunke <kenn...@whitecape.org> wrote: > On 11/18/2013 12:58 PM, Emil Velikov wrote: >> On 18/11/13 01:08, Keith Packard wrote: >>> libudev doesn't have a stable API/ABI, and if the application wants to use >>> one >>> version, we'd best not load another into libGL. >>> >>> Signed-off-by: Keith Packard <kei...@keithp.com> >>> --- >>> >> Hi Keith, >> >> Did you had the chance to look at src/gallium/targets/egl-static/egl.c? >> It has a different implementation of drm_fd_get_pci_id, whenever udev is >> not available. >> >> AFAICS it goes back to the kernel via the relevant ioctl to retrieve the >> deviceid/chipid. Currently all but nouveau provide such information. I'm >> thinking that this approach might be more reasonable for those concerned >> with portability of the udev bits (think on *BSD). >> >> I'm not nitpicking, just thought you might find this interesting. >> >> Cheers, >> Emil > > Possibly. But looking at that code, it either: > 1. Uses libudev > 2. On Android only...strcmps the driver string to guess the family and > then uses kernel ioctls... > 3. Fails. > > The Android only nature makes me a bit wary.
The string mapping of the kernel driver name to a dri.so is what I kinda expected to be used as the generic thing. Imo we don't ever need the pci id in common code, drivers can load that through a private ioctl from the kernel (like i915 and radeon do) or load some other device id from somewhere (nouveau has that at the special reg offset 0 in the bar, also exposed through some ioctl iirc). That way we also avoid hassles on SoCs which lack enumerable buses. And due to abi guarantees those drm driver names will stay the same forever. Also there's the entire drmOpenByBusid stuff which gives you at least something reasonable for pci devices (not anywhere else though), so we could do that dance in reverse if we want to have a pci id based lookup. Anyway I've never read through the loader code, just figured it won't hurt if I drop my uninformed opinion ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
