xserver ABI freeze policy (was: [PATCH] hw/xfree86: Restore API compatibility for cursor loading functions)

Keith Packard keithp at keithp.com
Mon Apr 28 15:59:32 PDT 2014

Aaron Plattner <aplattner at nvidia.com> writes:

> Changing the ABI at the last minute, even if you bump the ABI version 
> number, defeats the purpose of that.  In this case, I just added support 
> for ABI 17 so that driver that in theory will support the upcoming 
> xserver 1.16 can be released relatively soon.  If we bump the ABI to 18 
> now, then you'll make the changelog entry I added a lie.

1.16 is scheduled to be released at mid-year, we've still got two months
to go. The freeze process for the X server takes half of the development
cycle, and we're now one month into that.

I'm not willing to ship 1.16 with the API that was released at the
feature freeze; it has a bug where existing drivers would
build and mostly run, except that cursors would fail in mysterious ways.

That's clearly not acceptable for the 1.16 release. We either need an
API change that breaks compilation (so that users are forced to fix
them), or a cross-version compatible API. A cross-version compatible API
is obviously preferred as that will allow people to separately migrate
driver packages to the new API as they please.

Let's list some options we have here:

 1) Leave the code as it was at the feature freeze. Existing drivers,
    when recompiled to match the new ABI version, will fail.

 2) Leave the API/ABI as it was at the feature freeze and silently
    ignore the return value from the cursor loading functions. This
    will let existing drivers work, but will remove the new
    functionality from 1.16.

 3) Fix the API by adding the new _check versions of the functions. This
    would require an ABI version bump. Drivers using the new function
    would get new functionality. Drivers using the old function would
    continue to work as before.

 4) Fix the API as above, but move the unchecked version of the function
    to the end of the structure. It seems like this would also require
    an ABI version bump so that the server could know that the driver
    allocated a large enough data structure to have the new entry though.

The only way I see us preserving the version 17 ABI is to choose 2)
above, and even then I'd suggest changing the return type back to void
so that drivers don't expect to see the return value used in this server

keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140428/8ab28dbe/attachment.sig>

More information about the xorg-devel mailing list