[Xorg] Notes from release call
daniel at freedesktop.org
Fri Jul 9 19:00:10 PDT 2004
On Fri, Jul 09, 2004 at 12:34:29PM -0700, Eric Anholt wrote:
> - keithp explained the debrix work on making the server use .so
> modules. We should be able to produce .so modules that retain
> cross-platform compatibility for anything using ELF by using the libc
> wrapper, as long as the modules avoid certain hazardous functions
Right. As long as you can assume the same processor platform, then all
you have to do is avoid platform-specific stuff: make sure your module
works with a baseline libc, and the X stuff.
> - debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
> on autotooling the x server but have found sticky issues with modules
> involving references to global symbols. They've been fixed in that
> tree, mostly, but this may prove to be a hazard for vendors moving to
> .so modules
Global symbols are OK, but they *must* be resolved at load time; they
cannot be lazily resolved. This means that the ATI driver, where ati had
global symbol deps on atimisc/r128/radeon, while the reverse was also
true, could not be loaded. Ever.
Right now, our compromise is that Load "ati" works, but
atimisc/r128/radeon doesn't. The current thinking (well, for me anyway),
is to make a fake libatimisc/libr128/libradeon which just depends on
libati, and then rename the real ones to libati_atimisc, or whatever.
> - We should make our modules as .so, which gives us more architecture
> support and debugging ability, but retain the old loader if it proves
> difficult to make the switch fully. We could also take vendors' .a
> modules they produce and convert them to .so using ld probably.
objcopy is good. You want objcopy. If someone adds XFree86-ELF support
to this, we could use objcopy to do a conversion to arbitrary formats.
> Modularizing the build:
> - keithp had volunteered, eich had volunteered to help, but progress has
> stalled due to lack of time.
> - keithp doesn't have time until at least 3 weeks from now
> - Many, but by no means all libraries have been autotooled in the xlibs
> project, so we have a basis to work from
> - Modularizing of xorg can be done incrementally. First, rearrange
> includes directory to make modular while retaining imake build, which
> allows the libs to be done. Later the xserver autotooling can be
> brought in, at which point the imake build can be left to rot.
I have been doing a lot of modularisation work, but all in modular trees
at this stage.
> - If we move the new fields in PixmapRec to the end, we shouldn't have
> any binary compat issues, because nobody should be statically allocating
> PixmapRecs (since they wouldn't have the privates), or at least if they
> do, the rest of the server shouldn't be seeing them.
You can keep binary-compat if you add new members to the end of
Daniel Stone <daniel at freedesktop.org>
freedesktop.org: powering your desktop http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the xorg