On Friday 31 December 2004 06:04, Michel DÃnzer wrote: > On Thu, 2004-12-30 at 14:20 -0500, Adam Jackson wrote: > > - Option 3: Move libdrm from the DRI drivers into libGL (dlopen linkage) > > Pros: Minimal server impact. New libdrm could be shared between client > > and server. With a little cleverness [2], doesn't break the libGL/driver > > ABI, so drivers and libGLs from both sides of the change can be mixed > > freely. > > How would this work with an old libGL and a new driver?
Ack, it doesn't. Good catch. The only way would be LD_PRELOAD=/usr/lib/libdrm.so, but that's not acceptable. Since the drivers are opened RTLD_NOW there's no chance for the driver to detect this, and the scenario assumes no changes to libGL. However the LIBGL_DEBUG message would almost certainly mention a missing drm symbol, which might be good enough if we add it to the (desperately in need of cleanup) troubleshooting FAQ. That may be a sacrifice I'm willing to make. People using releases would get matching sets. Even people building DRI drivers from Mesa will always get matching sets. If the snapshots (wherever they live now) don't include libGL in the driver pack, they probably should. For options 1-3, totally switching this over may be an X11R7 kind of thing where we break APIs in the name of progress. However... > Otherwise, this sounds best to me, or option 5 maybe. I think I'm leaning towards options 4 or 5, as having minimal impact now. In the future we'd link the server against libdrm (or the drivers, in a dlloader world) and ignore Load statements for drm and GLcore. (dexconf generates config files with explicit load statements for drm and GLcore, even though it shouldn't.) By that point libdrm would have a canonical location in the filesystem, so it would be a true shared object. All of this really makes me want to revive debrix-extensions-glx. Hacking this stuff from within the monolith is such a hassle. - ajax
pgpzNlgJqp6oL.pgp
Description: PGP signature
