Hi Mark, On Thu, Sep 02, 2010 at 12:19:34AM +0200, ext Mark Kettenis wrote: > > > > 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.
Nope, I won't need any #ifdef juggling: http://cgit.freedesktop.org/~vignatti/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?h=bus-cleanup-take3 and that's the main exercise of doing xserver's modularization: to be succinct without spoil with the rest of the code. Now, look the code above and tell me what do you think is better: a code with ifdef or the one I pointed there. Note that I'm not refusing your opinion, I'm just trying to make the code more clear for everyone. > > 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. Ok, I'm fine with it (even IOADDRESS being a hw related definition, which conceptually shouldn't be in xfree/common/, but is an okay temporary approach) > Expect opposition from me on removing domainIO/domainIOBase though. well, it's messing Entity related code with int10's. The former is useless nowadays and should go away. Why you'd oppose to it? Tiago _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
