X server 1.6 release schedule

[Paulo César Pereira de Andrade]

> On Sat, 2008-11-15 at 15:57 -0200, Paulo César Pereira de Andrade wrote:
>> > I volunteered to manage an X server 1.6 release, tentatively scheduled
>> > for the end of the year (yes, this year, 2008). This release will
>> > include DRI2 and RandR 1.3 support. I'd like to know how much of the
>> new
>> > Xinput stuff will be ready in time.
>>
>>   I guess it will be required to skip
>> https://bugs.freedesktop.org/show_bug.cgi?id=14730 again.
>> I had that patch working for X Server 1.4 one year ago, and for
>> git master before 1.5 was "branched". But did not test it much
>> recently. Anyway, it probably should stay this way, as the patch would
>> be more useful when/if Xorg started using a sdk, with a compromise on
>> backwards compatibility. But at the rate new features are being added,
>> this is unlikely soon :-) Also by only exporting symbols that really
>> should be visible, you get a compromise.
>
> Actually, I've been meaning to get this merged for a while now.  I'll be
> happy to take a look at it again.

  I think the patches should still apply (besides some patches for
mfb and glx/*.c). But I can review it again.
  Actually, I built a framework to work on this. I added the xedit
ctags interface just for this :-), and wrote a perl script that will
use objdump to list all external symbols provided/required by modules
and X Server, and print where the symbols are found.
  The logic for finding where a symbol is defined is very simple:
o Check X Server and libraries linked to it.
o Check all other modules in the module path, the script can handle
  multiple module path, but it cannot ensure the driver is actually
  loading a module.
  It will also print a warning about multiple definitions.
  I think I got all patches required for modules already commited,
but not for libraries (to define as weak some symbols also defined
in the X Server).
  Points where special attention is required:
o Usage of LoaderSymbol() or dlsym. For this I just grep'ed everything,
  and resolved by hand the missing symbols. Check hw/xfree86/i2c/*.h
  for awesome samples, where it will cast to a function and call the
  value returned by LoaderSymbol(). The ati multimedia drivers had
  some very similar usage, but that should have been fixed now, only
  missing feature there would be to be able to load the different
  multimedia drivers, as they all provide symbols with the same name,
  instead, it should provide a vector of driver callbacks. But see
  xorg/driver/xf86-video-ati/src/theatre.h for a sample of how to
  correct that usage of LoaderSymbol without breaking abi.
o Symbols also defined in libraries. Best example is libXfont. if
  the X Server is plainly compiled with -fvisibility=hidden, it
  will not say there are missing symbols and use the stubs in libXfont,
  and the script will not even show the duplicated symbols (gcc can
  make some very aggressive optimizations when a symbol is not
  accessible from other shared objects, and just inline the "hidden"
  function).
o Some symbols are a pain to find. My idea is to make some extra
  patches just to make finding symbols (with your preferred text
  editor :-) easier. The most important one is change things like:
  -%<-
  #define NAME(function)    prefix ## name
  type NAME(foo) { bar }
  -%<-
  to:
  -%<-
  #define BODY  bar;
  type prefix_foo { BODY }
  -%<-
  This also to handle the other common case of symbols "hard to find":
  -%<-
  type
  #ifdef FOO
  foo_name
  #else
  bar_name
  #endif
  (arguments) { baz }
  I don't remember if there are any files generated on the fly now,
  after the removal of mfb and xfxbpp
  -%<-
o There are drivers that access "private" symbols, that is, symbols
  not in /usr/include/xorg/*.h.
  I don't have a tool to generate information about these, but once
  I posted a list of symbols used by modules that are not in the
  sdk, and symbols in the sdk that are not used by any module (the
  script tells about symbols exported but not used by any module).
  But when/if making symbols easier to find, generating such list
  even by hand would not take much time.

  In the worst case, the "framework" is still good to find things
like macros being compiled as a call to a function (due to not
including the header with macro definition), or just plain code
that calls functions no longer available.

  Also, besides the temptation, I did not "ansify" the X Server
code to attempt to reduce patches size (it is still huge, besides
having one patch addressing a different problem).

  Another detail is that it really needs some major review to
decide what really needs to be in the sdk, because to have it
properly implemented, everything in /usr/include/xorg/*.h should
be made available, and I think like only half of those symbols are
tagged _X_EXPORT.

  Yet another detail, it may be a good idea to also use gcc's
visibility pragmas before inclusion of headers of external libraries.

  My original patches to util/macros was to have a @@HIDDEN_SYMBOLS@@
and @@PUBLIC_SYMBOLS@@, but probably it is better to just set
XORG_CFLAGS accordingly.

> - ajax

Paulo