After much discussion in the original thread, it looks like people are willing, even eager, to make very significant changes to the loader / driver interface. Good stuff! If we're going to do this, we should figure out what we want the primary "form" of the interface to be.
Looking at the existing loaders (i.e., libGL and libglx), there are three primary forms the interface could take. I strongly believe that we should be explicit and up-front about defining this. Part of the problem with the existing interface, especially for IHVs, is that it is poorly documented. The three forms currently in use are:
1. Lots of statically exported functions. Older versions of libGL just exported a bunch of functions (e.g., XF86DRI*, _glapi_*, etc.) that drivers would call.
Pros: Very simple interface. People are used to just calling functions.
Cons: Very difficult to expand the interface in a binary compatible way.
2. A few statically exported functions and a glXGetProcAddress-like function. This is the way more recent versions of libGL work.
Pros: Much easier to add new and remove old interface functions.
Cons: Juggling a large, ever increasing, number of function pointers in a pain. Requires a lot of tedious, up-front work for the driver.
3. Loader passes a method table into the driver. libglx, to a certain extent, takes this approach through the use of __GLimports (include/GL/internal/glcore.h).
Pros: If the structure is tagged with a version, it is very easy to add new interface functions. Much easier for drivers to deal with a single, externally supplied structure of function pointers.
Cons: Can't remove functions from the interface. We have this same problem in DRI now (e.g., bindContext and bindContext2 in __DRIcontext). Structure versioning can have its own problems within the driver (e.g., lots of 'if ( api->version >= FOO ) { ... } else { ... }' blocks).
My personal opinion, and I think a couple people have voiced similar sentiments, is that option 1 is right out. As far as option 2 and option 3 go, I'm a bit torn. We already use option 2 to import functions into the driver, and we use option 3 to export functions from the driver. I may give a /slight/ nod to option 3 because, by virtue of collecting all the entry-points in one place, it makes it much easier to generate unified developer documentation (all hail doxygen!).
Thoughts?
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
