ABI Changes (was Re: Graphics Driver Frameworks and Security)

[Andy Ritger]

Thanks, guys, for bringing up the topic of ABI changes.

To set the record straight, there have been several ABI changes
between Xorg 7.0 and the 7.1 RCs; not all of the ABI changes may
be well known (or documented?).  The ABI changes that I am aware
of are:

    - A devPrivates field was added to GlyphRec; this is needed,
      for example, to store glyph data in video memory; impacts XAA,
      EXA, and any acceleration architecture.

    - The XV PutImage driver proc was updated to take a DrawablePtr;
      this is used so that drivers can integrate their XV
      implementations with Damage and Composite.

    - The XF86 libc wrapper was removed.  Drivers/modules need to
      link directly against the C library, rather than call the
      XF86 libc wrappers.  Fortunately, dlloader drivers without
      xf86 libc wrappers can also work on older X servers.

    - Field alignment within the DrawableRec data structure on 64-bit
      platforms (bug 6924); this change was made as part of the
      fix for bug 6438.  This change seems unfortunate, because A)
      DrawableRec is so pervasive throughout the whole X server and
      drivers, it is hard to abstract away the ABI differences,
      B) bug 6438 really could have been fixed without changing
      the ABI (DrawableRec could have been padded to retain the
      same alignment after the fix), C) there seemed to be some
      awareness that the change would alter the ABI, yet there was
      no announcement or reving of the ABI version.

      It may be dangerously close to 7.1 release, but I would like
      to suggest padding the DrawableRec data structure such that the
      id field is still only 32-bits, as it is now (and therefore
      still fixes bug 6438), but that the fields retain the same
      alignment that they had previously.  Either Aaron Plattner
      or I will provide a patch to bug 6924.

Other ABI changes in the works for post-7.1 include the PCI
management overhaul, and the removal of the MAXSCREENS constant.

>From NVIDIA's perspective, we understand that ABI breakages are
needed for the advancement of X, and we certainly do not want to
inhibit that.

At the same time, it seems good for ABI breakages to be thought-out
and deliberate.  It is also desirable for there to be fewer ABI
changes; if several ABI changes can be made at once, then we can
have fewer revisions of the ABI, which means fewer ABI versions to
support.  Fewer ABI versions is good not only for IHVs like NVIDIA
and ATI, but it is also good for driver developers, packagers,
and distributions too, because they have less complicated version
dependencies to keep track of and a given version of a driver
will work with a wider range of servers.  I would think this is
particularly relevant with the modularization of the X source tree,
and the decoupling of X server and X driver releases.

There is also a difference between ABI changes that can be managed
within a single build of a driver versus ABI changes that really
require multiple builds of a driver.  Something like the devPrivates
addition to GlyphRec can be dealt with at runtime, but a change as
pervasive as the alignment of DrawableRec's fields is difficult to 
manage within a single build.

Thanks,
- Andy Ritger



On Tue, 16 May 2006, Alan Coopersmith wrote:

> Christoph Hellwig wrote:
> > On Tue, May 16, 2006 at 08:28:56AM -0700, Alan Coopersmith wrote:
> >> (BTW, someone should point out to Theo all the bugs & e-mail we're getting 
> >> now
> >>  about the ATI closed drivers not working on Xorg 7.1 because we chose to
> >>  break the vendor binary drivers in this release.  Guess we've failed our
> >>  lapdog role.)
> > 
> > The real problem is that X.org doesn't break the ABI often enough.  If
> > you make sure the ABI breaks in every release they'll stop complaining
> > real soon.
> 
> They'll stop complaining because they've gone back to Windows or MacOS, where
> people aren't actively trying to break the drivers they use.   Breaking ABI
> won't convince the vendors to open source their drivers, it'll just convince
> them it's more expensive and less profitable for them to support Xorg, and
> make them more likely to give up.
> 
> -- 
> 	-Alan Coopersmith-           alan.coopersmith at sun.com
> 	 Sun Microsystems, Inc. - X Window System Engineering
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>