My proto/ battle plan (Re: [PATCH] Refactoring of dixutils.c)

[Tomas Carnecky]

On 8/3/10 3:55 AM, Fernando Carrijo wrote:
> Cc-ing Tomas
> 
> Tiago Vignatti <tiago.vignatti at nokia.com> wrote:
>> I'm looking forward now to see proto/ created, as discussed.
> 
> It seems Tomas is already working on this area. See here:
> 
>   http://marc.info/?l=freedesktop-xorg-devel&m=128050875331099&w=3
> 
> So, unless he prefers me to do, I'll leave the proto/ issue in his hands.

Well, I can describe what I'm doing right now. I'm starting with the
simpler extensions (I have DPMS mostly ready, but still need to finish
the integration into the build system), but it'll take me a few more
weeks/months until I'm ready to generate xproto from the xml definition.
So if you want to move dix/tables.c and related files to proto/, go ahead.

I envisioned proto/ to contain everything that has to do with the
protocol en/decoding, split into different files. The first three files
are generated, the fourth is handwritten:

 - foo.h:
	definitions of types, enums, defines etc.
 - foo-wire.h:
	definitions of request/reply structures, only useful in foo.c and
foo-glue.c, thus split into a separate header.
 - foo.c:
	implementation of the protocol de/marshaling methods, and
FooExtensionInit().
	These methods read and swap requests, then call methods from
foo-glue.c, take
	the reply, swap it and write back to the client.
 - foo-glue.c:
	The glue between the de/marshaling methods and the actual implementation.

The other part of each extension is the actual implementation, currently
scattered around various top-level directories (randr, render,
composite, damage), Xext/ (dpms, xv, bigreq, screensaver, xres etc) and
some even in hw/xfree86/ (dga, xf86vidmode). I didn't want to move that
second part into proto/ because it's technically not protocol-related.
So now each extension is split into two libraries: libproto-foo.la and
libext-foo.la. Each server wanting to implement this extension has to
link with both those libraries.

I've then tried to figure out how/where/who decides which extensions
link into which server. The logic is spread around configure.ac and the
makefiles. This is what I found out so far:

- There are extensions which are always enabled and those which are
conditionally enabled: fixes, randr, render, damage, xi, shape, xkb can
not be disabled, others have a configure switch.

- Just because an extension is enabled doesn't mean the server has to
link with the extension library. XFixes has ifdefs inside dix/, but even
if XFIXES is defined, the server will not depend on any symbols from
libxfixes.la. Same with DPMS: when enabled, DIX will not depend on any
symbols which are defined in the dpms sources. How is that possible?
It's because DPMS related global variables are declared in dix/globals.c
(which, along with mi/miinitext.c is a huge mess of ifdefs). I moved all
methods and global variables that are related to DPMS into
libext-dpms.la, so now if DPMS is enabled all servers have to link with
libext-dpms.la. But that can be easily handled inside configure.ac (for
a certain definition of 'easy', see next point).

- Extensions can depend on each other, the order in which the libraries
are passed to the linker is important. That alone makes configure.ac and
the makefiles so much more complicated. I tried to classify in-tree
libraries into different types: Those that need to be linked into all
servers (DIX_LIB, OS_LIB etc), extensions which are optional but when
enabled have to be linked into all servers (currently none, but with my
proposal libext-dpms.la will become such library) and extensions which
are optional but only depend on support in the DDX so can be linked into
each server separately (eg. randr).
Of course XSERVER_LIBS (set of libraries required by all servers) is not
used by all servers, some use OS_LIB, DIX_LIB, MI_LIB directly. And one
can't easily add the always-enabled extensions to XSERVER_LIBS because
of, well, the dependencies.
Then there's MAIN_LIB which is linked into all servers, but not part of
XSERVER_LIBS (to see why, take a look at test/Makefile.am) and several
servers include various libraries multiple times: xquartz includes
OS_LIB, MI_LIB, DIX_LIB and MAIN_LIB twice, xwin includes OS_LIB and
MI_LIB twice etc. I guess it's easier to just pass the libraries
multiple times to the linker instead of having to worry about dependencies.

tom