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

[Matthieu Herrb]

On Sat, Sep 24, 2011 at 12:35:30PM -0700, Jeremy Huddleston wrote:
> 
> 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).  

Hmm CARD32 is a define that imho should only be used at protocol level
definition and coding/decoding. To use exact sized types in the server
I prefer C99 types like uint32_t. 

Bug ok.
> 
> >> 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. 

Hmm it fails to run because it seems that pci_device_map_legacy()
never actually made it in libpciaccess(). I found patches in may for
it but no actual commits to libpciaccess. Am I looking at the wrong
repository ? (git.freedesktop.org/git/xorg/lib/libpciaccess )

This is a major blocker.

> > 
> > 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. 

Yes that's good and we could even benefit from that on OpenBSD's
architectures that don't have PCI bus.

> 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. 
> 





-- 
Matthieu Herrb