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

[Jeremy Huddleston]

On Sep 24, 2011, at 03:01, 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.

I wouldn't consider that "massive".  Multiple failures of similar types requiring redundant changes to many different drivers.

> 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 think this is a good step in the right direction, and if we're going to go through a small amount of pain for little gain or a moderate amount of pain for better gains, I'll pick the latter.  IOADDRESS is used for multiple types (ioports) in the legacy API, so it's better to just get rid of it and avoid confusion/collision.  It's not *THAT* hard to change the types in the drivers.

If the drivers need multiple PCI domains, then perhaps this is a good time to start divorcing those drivers from using the bus support in hw/xfree86 and start using libpciaccess directly.