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

[Mark Kettenis]

> Date: Sat, 24 Sep 2011 15:16:49 +0000
> From: Daniel Stone <daniel at fooishbar.org>
> 
> Hi,
> 
> On 24 September 2011 13:26, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > It's still work. Â And it probably inflicts pain on people like Micahel
> > Daenzer who maintain drivers for older xserver releases. Â And it also
> > inflicts pain on people who maintain drivers out of the git
> > repositories on freedesktop.org. Â Like the xf86-video-intel driver we
> > have on OpenBSD with forward ported modesetting changes.
> 
> So, given that this apparently causes so much work for you: would it
> not be easier in the long run (as well as vastly more sensible) to
> work on KMS support so you don't need to maintain a forked driver from
> now until forever?

Yes.

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

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.