hotplug plans - issue 1 (ideas welcome)

[Dave Airlie]

So I've fleshed out most of a working solution for hotplugging and gpu
switching but I've started wondering how to move ahead with
upstreaming and finishing it off.

The quick high level overview is I introduced an impedance layer
between the protocol types and a new set of driver types, the
impedance layer translates the protocol types of Screen, GC, Drawable
(Pixmap+Window), Picture to the driver types of DrvScreen, DrvGC,
DrvPixmap and DrvPicture.

Now above the impedance layer lies all the protocol processing code,
and below the layer lies all the drawing code. The layer does all the
window->pixmap translations including composite unwrapping. So all the
drivers see are pixmaps + pCompositeClip inside the GC/Picture. The
operations are transformed into a coordinate space of the pixmap being
rendered to.

So currently I've duplicated most of the fb, exa and lots of pieces of
mi code into my drv subdir and replaces all the types and removed all
the code.

Now I have three strategies for dealing with this:

a) disruptive - move all the code from above impedance layer to below
impedance layer, stop shipping it above the impedance layer. Make the
new API the only driver API we expose, fix problems like a mad bastard
in the impedance layer (its not perfect yet).
This saves us carrying two copies of mostly the same code. It does
mean a bumpy cycle, and it will make it harder for drivers to
build/run against older/newer servers.

b) duplicate and rename: fb->drvfb, exa->drvexa, shadow->drvshadow,
damage->drvdamage, mi->drv. Now we have duplicated stacks which
drivers use depending on whether they support the new or old ABIs. The
server can maintain both APIs but hotplug and features like that are
only available to drivers through the new API. After a couple of
cycles we deprecate and remove the old API and all the original code.
The big disadvantage is we carry two sets of code for a lot of stuff
and it isn't shared.

c) try and share the code as much as possible: This relies on keeping
the internals of the exposed structures quite similiar. We have to
take every file that can be shared and template it to deal with both
sets of types, above and below the impedance layer. We would probably
have to generate a large tables of #defines to prefix all the function
names with a new identifier and also rework the code where there are
differences or cannot share. This could be something as leaving the
current types and function names in place and using a large sed
scripts to build new C files on the fly that we compile into new
modules, or something more complex involving changing function names
and types so the code gets built in one of the other modes.

This is of course only one of the issues I face, but I would need to
get some ideas on merging and keeping the tree in some ways stable.

Dave.