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

[Andy Ritger]

Thanks for the responses.  I'll respond to both Matthias and Felix below:

On Wed, 17 May 2006, Matthias Hopf wrote:

> Andy,
> 
> Egbert doesn't have internet connection ATM, that's why he's not really
> responsive at the moment. I just phoned him and can tell his point of
> view about your major concern:

Ah, OK.  Thanks for checking on that, Matthias.

> On May 16, 06 23:00:56 -0700, Andy Ritger wrote:
> >     - 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.
> 
> Egbert's point of view is (AFAIU) that in the long term the current solution is
> the right one, removing as many #ifdefs as possible.

Yes, agreed.

> He doesn't have any issues with a temporary solution that uses 32 bits
> always, as long as everything works not only for 32/64 bit but also for
> both endianess.

Yes, agreed.

> But he also assures that there are more, similar issues, that have to be
> addressed, so there *will* be some pain for binary only graphics
> drivers, but these changes could well be combined in (hopefully) a
> single ABI breakage.

Yes, combining those changes would be great.  If there are specific
known issues along those lines, I can offer help in working on them,
if that helps to stage when the changes go in.

> Still, the ABI is more likely to change nowadays
> compared to former development cycles.

Yes, understood.  I suppose maybe I'm just trying to prevent the inevitable :)

> However, as 7.1 is pretty close, final judgment whether some patch will
> go in or not before 7.1 is rolled can only be made by the release
> manager.

Agreed.

On Wed, 17 May 2006, Felix Kühling wrote:

> Isn't it too late for this? The ABI has changed and the ABI major
> version was bumped already due to other changes. You will need separate
> driver binaries for Xorg 7.0 and Xorg 7.1. So what's the benefit of
> partially restoring the old ABI at this point?

The benefit, from my perspective, is the difference in the type of
ABI changes.  Without the DrawableRec change, a single driver binary
might be able to run on both 7.0 and 7.1: at run time, you can
detect the ABI version and do things like cast a GlyphPtr to the
right type for the right ABI.  Since the amount of code a driver
typically needs for managing Glyphs is relatively small, this is
managable.  The same is true for the XV proc (plug in a different
proc based on the ABI version).  We've done minor things like this in
the past; e.g., as new xf86 layer functions are exported to drivers.

Having a single driver binary is nice because it simplifies the
installation process and leaves less room for problems arising from
the wrong binary getting installed.

But you are all correct that this is something IHVs shipping their
own drivers need to deal with.  I was just hoping to minimize it
in the short term.

Thanks,
- Andy



> CU
> 
> Matthias
> 
> -- 
> Matthias Hopf <mhopf at suse.de>       __        __   __
> Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
> Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de
>