[PULL] bus cleanup, darwin hw/xfree86, build regression fixes

[Jeremy Huddleston]

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.