removing PCI dependency from xserver

[Mark Kettenis]

> Date: Wed, 1 Sep 2010 18:00:57 +0300
> From: Tiago Vignatti <tiago.vignatti at nokia.com>
> 
> Hi all,
> 
> Right now, we have two impediments preventing me to put libpciaccess optional
> in xserver:
> 
> 1. fbdevhw module, which is PCI tied
> 2. IOADDRESS type (weird) definition
> 
> My last attempt to get rid of PCI in fbdevhw [0] was only commented
> by Mark Kettenis. He mainly pointed the existence of fbdevhw. For
> instance, if it should go to Linux specific directory (which for me
> is off topic, but totally valid argument) or if the relation PCI <->
> fbdevhw should be kept (which is not true; I had already an OMAP
> based device without PCI using fbdevhw interface). What you thing?

Look, you'll have to introduce some sort of #ifdef-able #define to
compile the core xserver code without support for PCI.  Why don't you
just leave all the code in fbdevhw.c and use the same #define to
conditionally compile fbdev_open_pci().  You can add a dummy version
that causes a fatal error if you compile without PCI support, and
everything else can stay as it is now.

> For 2. I tried an approach, that Mark also commented [1], but maybe
> I should be more carefully, explained better my intention. Mark
> basically complains that my patch hinders readability. But I'm
> against with his argument: all variables using IOADDRESS in such
> patch has a very suggestive name. Anyway, after all, all the code on
> the whole patch is due to be removed soon (GetClocks is a hack and
> domainIO/domainIOBase is remnants of entity resource code). To
> remove this code requires too much manual effort now though.

Just add a

typedef unsigned long IOADDRESS;

in a strategic place when you compile the xserver without PCI support.
If nothing uses IOADDRESS anymore, you can simply remove it.

Expect opposition from me on removing domainIO/domainIOBase though.