On Sep 24, 2011, at 09:31, Matthieu Herrb wrote: >> IOADDRESS is used massively throughout the drivers. I really don't >> see why it needs to be removed. Leaving the typedef in xf86Pci.h will >> save you/us a lot of work. At that point you might as well drop the >> changesto remove IOADDRESS usage in the int10 module. > > I agree with Mark on this.
Ok. Then how about leaving the PCITAG and IOADDRESS typedefs in place but deprecate their use. I also think we should change them from unsigned long to CARD32 for better compatibility with pciaccess (yes, ABI break, but we know that). >> Still only a partial review; looking into the changes to the >> interfaces that map video memory now. > > I wanted to look, and more importantly test them, but so far the > IOADRESS fallout (plus a few other stuff induced by the usual > autotools churn) has caused the build of drivers to fail. I'll restart > the build with the IOADDRES removal reverted and see how it goes. > > One 1st comment though: apparently the intension is to remove the old > MTRR support backend completely (since its now done by libpciaccess > directly) but some bits of it have been left in place in > bsd/i386_video.c. Is that intentional ? Just in case it wasn't clear already, I'm doing this so that I can turn *off* bits that require pciaccess in my builds on osx. I can do minimal build fix failures across the board but I can only test with what I have. I have a ppc and intel linux box and can test vesa, vmware, nv, nouveau, ati, and intel (with 1 pci domain) which covers the common cases. I am brand new to the hw/xfree86 and libpciaccess codebase, and these changes are fairly extensive, so I'm glad to see these changes getting solid attention and reviews (thanks). I really wish ajax would speak up about these changes but he's been mostly silent. It's entirely possible that he just missed that MTRR code in bsd/i386_video.c. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel