> Date: Wed, 1 Sep 2010 18:00:57 +0300 > From: Tiago Vignatti <[email protected]> > > 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
