[Xorg] Notes from release call
elylevy-xserver at cs.huji.ac.il
Sun Jul 11 06:16:37 PDT 2004
25 Aug means to release a beta preety soon?
When are we going into code freeze?
should we brench into release and continue to advance in the tree?
On Fri, 9 Jul 2004, Eric Anholt wrote:
> Here are a few notes I'm writing down from the release call, in case we
> don't get minutes. I wasn't paying attention to who said what, so these
> are just my impressions/conclusions from the call and are not complete
> in any way.
> First topic was .so modules:
> - 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
> - 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
> - 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.
> - Has anyone tested .so modules cross-platform? Nobody on the call at
> least. anholt was volunteered for testing.
> 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.
> - anholt has attempted to do Composite support for XAA, which was never
> completed, but the first thing to do would be to make a wrapper at the
> miext layer that retained binary compatibility.
> - 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.
> - anholt concerned about doing Composite wrapper because of lack of
> experience, eich suggested he could. (I'm attempting it anyway)
> - Timing of next release: two months? end of year? next year?
> - Proposed that we release in time for Fedora Core 3
> - FC3 schedule would require a release by Sep 6?
> - Proposed that we target having a release by Aug 25
> - General agreement found.
> - What should be in release? Composite/Damage/Fixes found general
> agreement. What else? Call put out to xorg@
> Eric Anholt eta at lclark.edu
> http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
> xorg mailing list
> xorg at freedesktop.org
More information about the xorg