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

[Matthieu Herrb]

On Sat, Sep 24, 2011 at 12:01:02PM +0200, Mark Kettenis wrote:
> > From: Jeremy Huddleston <jeremyhu at apple.com>
> > Date: Fri, 23 Sep 2011 20:21:54 -0700
> > 
> > On Sep 23, 2011, at 16:22, Jeremy Huddleston wrote:
> > 
> > > I'm also testing it on tifa32-linux tinderbox:
> > > http://tinderbox.x.org/builds/2011-09-23-0007
> > 
> > A few failures in various video drivers ... but they should be
> > simple enough to address (a quick check looks like #include
> > <pciaccess.h> will probably take care of some of the issues)
> > ... wouldn't it be great if the drivers were in the tree so this
> > could all be addressed together... /duck
> >
> > I'll start working though the various drivers next week and leave it
> > to you if you want to merge this before that is all done.  Waiting a
> > bit longer will also give others (Mark) time to review.
> 
> It's more than a few drivers.  And as far as I can tell that massive
> breakage is due to two things:
> 
> 1. The removal of domainIOBase from struct _ScrnInfoRec.
> 
> 2. The removal of the IOADDRESS type from xf86Pci.h.
> 
> Only a few drivers actually use domainIOBase, but among those are
> xf86-video-vesa and xf86-video-vmware drivers, which are pretty
> important ones.  The others are xf86-video-ark, xf86-video-sis and
> xf86-video-tdfx.  These drivers are fairly easy to "fix" by replacing
> domainIOBase by 0.  That will of course break the usage of these
> drivers on systems with multiple PCI domains.  That can only be fixed
> by proper conversion of these drivers to use the appropriate
> libpciaccess interfaces instead of assuming legacy space is mapped and
> doing in/out directly.  None of these drivers matter to me for
> OpenBSD/sparc64, which is the only architecture with multiple PCI
> domains that we run on.  But Linux people might care, for example for
> POWER systems.  Remember that multiple domain support was one of the
> reasons for deveoping libpciaccess in the first place!
> 
> 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. 
> 
> 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 ?

-- 
Matthieu Herrb