[PATCH xserver 0/2] glx/dri2: Fix bug #50019.
Jeremy Huddleston Sequoia
jeremyhu at apple.com
Sat Jul 28 10:28:13 PDT 2012
On Jul 28, 2012, at 10:05, Julien Cristau <jcristau at debian.org> wrote:
> On Sat, Jul 28, 2012 at 09:58:46 -0700, Jeremy Huddleston Sequoia wrote:
>> Ok, so then what do we do about this? Is it really important enough
>> to break ABI, even considering that 1.13 is just around the corner?
>> I'd think not, but I'm willing to listen to arguments.
> I'm not sure why you say "breakage". Adding an entry point isn't ABI
> breakage. I don't think anybody is going to mix 1.12.3's libdri2.so
> with 1.12.4's libglx.so.
Right, sorry. That's ambiguous. By "ABI breakage", I'm referring in this case to the change in exported symbols (even just adding a newly exported symbol). I consider that breaking ABI, and you don't, but our disagreement over what constitutes "breaking" versus "changing" isn't really at issue. I'm just very cautious about API design, and I'd prefer to not get us into a jam if we can avoid it.
I agree that it's very unlikely that anyone would mix libglx.so and libdri2.so between versions, and yes of course making the symbol not exported would cause libglx.so to not be able to use it. The issue I'm concerned with is whether DRI2CreateDrawable2 will *only* be used by co-shipping code (ie code living in xserver like libglx.so) or if drivers (esp 3rd party binary-only drivers) might start using it directly. That will get us into a situation where some servers advertising the same ABI version have DRI2CreateDrawable2 and some don't.
More information about the xorg-devel