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

[Jeremy Huddleston]

On Sep 26, 2011, at 06:10, Mark Kettenis wrote:

>>> I don't really object to the canges to the in10 module (although the
>>> libpciaccess API uses uint32_t instead of unsigned int).  But please
>>> keep the IOADDRESS typedef until the majority of the video drivers
>>> have been converted to use the libpciaccess API to do port IO.
>> 
>> Cool, that sounds like a good plan to me.  Who's going to do it? Has
>> anybody actually got this hardware in a multiple domain machine, with
>> the time to do it? Can you say with a straight face that you expect to
>> see patches porting them to libpciaccess with full multiple domain
>> support within the next release cycle? Within the next year?
>> 
>> I know it might sound like I'm trolling, but these are entirely
>> serious questions.
> 
> Well, first of all, my statement wasn't meant to be interpreted in the
> narrow context of multiple domain support.
> 
> The IOADDRESS typedef is as much part of the old xserver PCI
> interfaces as it is part of the in()/out() support in compiler.h, and
> the various hacks to support thise calls on non-x86 architectures.  I
> believe ajax's goal with the new IO support in libpciaccess was to
> replace that stuff in compiler.h.  Unfortnately *not a single* driver
> has been converted to use these new interfaces.

Well at XDC, there was some pretty solid consensus among advocates for keeping drivers separate that API/ABI change wasn't a big deal and they would just react to such changes quickly when they were made as they have been in the past.

We can't have it both ways.  We either move drivers into the xorg-server tree and do ABI break cleanup all at once, or we push it and let driver maintainers react.

I have addressed your concern about the continued existence of the PCITAG and IOADDRESS typedefs, and that does help.  There are still 12 new build failures in drivers resulting from this:

xf86-video-chips
xf86-video-cirrus
xf86-video-i128
xf86-video-intel
xf86-video-neomagic
xf86-video-openchrome
xf86-video-rendition
xf86-video-tdfx
xf86-video-trident
xf86-video-tseng
xf86-video-vesa
xf86-video-xgi

Anyone interested in those drivers can merge my branch for testing and prepare those drivers for the change.  Almost all of them are:
error: 'struct _vgaHWRec' has no member named 'PIOOffset'

which is as you predicted.  If I read this API right, just using 0 instead will "fix" the problem in the short term for systems with one PCI domain.

> I'm interested in moving things forward here, and when the stuff being
> discussed here goes in, I'm likely to do some work on some of the more
> obscure drivers that I care about.  But I'm not really inclined to do
> that until some of the mainstream drivers make the move.