[Xorg] Notes from release call

[Daniel Stone]

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
> (setjmp/longjmp)

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
structures, yes.

-- 
Daniel Stone                                            <daniel at freedesktop.org>
freedesktop.org: powering your desktop                http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20040710/3a4c96b6/attachment.pgp>