stripping off "xf86-*-" from drivers

[pcpa at mandriva.com.br]

Quoting Michel Dänzer <michel at tungstengraphics.com>:

> On Mon, 2008-01-21 at 01:31 -0500, Bernardo Innocenti wrote:
>>
>> I have nothing against keeping simple, non intrusive
>> backwards compatibility bits (although backporting
>> patches is also possible).
>>
>> Not the case in pci-rework, MPX, XACE, etc.
>
> Definitely the case for pci-rework, see e.g. xf86-video-ati and -intel.
> I don't know for the other two examples, but I'd be surprised if it
> wasn't the case as well.

  I am not sure if something like this would be easy for most cases,
but some kind of compat module could be used, at least to help during
transitions.
  One easy example could be a "libc_wrapper" module, to provide
xf86<insert-libc-symbol> symbols, so that modules not recompiled could
continue working, usually some module by some vendor that provides only
binary modules.
  Ofcourse the "libc_wrapper" module is an easy case, a pci-rework
one could require significant extra work, and some subtle ABI change
could be almost impossible to know about, and this mainly because there
isn't any kind of "tag" or module version change when compiling the
module/server --with-foo or --with-bar.

>> Xorg drivers need to mess around several large data
>> structures of the core server.  How can we possibly
>> maintain binary compatibility while at the same time
>> evolving them independently?
>
> Why do you keep bringing up binary compatibility? We've broken it in
> about every modular xserver release so far, and I don't see anyone
> proposing to change that. The point is that it's usually not too hard to
> keep source compatibility across ABI breaks.

  The main problem is that there isn't a well defined API.
/usr/include/xorg files should be well thought (right now at least
build a directory tree there, preferably matching X Server tree would be
desirable), and there should exist some compromise with what is available
there. Most structure definitions should be in a /private directory, or
some *_priv.h if ever installed.

  Something that can help enforce an API is the _X_EXPORT macro. About
my experience using it:

  I have been running my X Server/modules compiled with -fvisibility=hidden
for some time, and have made it available a few days ago to Mandriva users
in cooker (devel packages). The patch for 1.4 branch is slighly over 16k
lines, but I added the _X_EXPORT macro to header declarations, as well as
source definitions.
  If there is interest I can work on a patch for both, 1.4 branch and
master.
  I also compiled modules with -fvisibility=hidden.
  I also made a perl script that parses output of objdump and simulates
loading of shared libraries, so finding missing symbols is easy. Usually
missing symbols are symbols with hidden attribute, or not even generated
as they are hidden and not used, but there are ofcourse cases like
symbols removed from the X Server (and breaking input modules, I think
from the video modules only savage has a call to vbeModeInit that doesn't
exist) and in modules compiled with "X Server 1.3 sdk" there were several
unresolved symbols that were actually macros, but the proper header was not
included.
  Whenever possible I also reworked some LoaderSymbol calls to directly
call the function. Save a few exceptions, like
xf86-video-intel/src/i830_dvo.c calls to LoaderSymbol where I just
_X_EXPORT'ed the proper symbols in the proper modules...

  Note that I am not trying to self promote myself or anything :-), just
telling about my experience, and the initial work on it, already in the
source tree was done by Adam Jackson.


> --
> Earthling Michel Dänzer           |          http://tungstengraphics.com
> Libre software enthusiast         |          Debian, X and DRI developer


Paulo