start of some pci cleanups

[Dave Airlie]

> > This just adds pci domain to the pcibusid struct and passes the
> > PciBusId struct around instead of passing bus,dev,func triplets.
> 
> As noted elsewhere, it breaks binary compatibility, and we're past the
> point in the Xorg 6.9/7.0 release cycle where we want to do that unless
> absolutely required.   And then once 7.0 is released, breaking it will
> become much harder since you'll have to coordinate individual releases
> of the Xorg server and all the separate drivers.

After talking to a number of people last week. I think we are the
point in 7.0 release where we can do this, earlier we would be too far
from a release...post-release it will be getting impossible.... this
won't break anything, it is very obivous, I also have a patch to
remove PCITAG completely as it is a hack that we don't need if we are
passing around real pciinfo structures, but I'm a bit more worried it
might break things.... this along with Jesses IO interface changes
allow us to support a lot of systems that will come along in the
future in a clean fashion..

Yes we can fix all this code up for binary compatibility reasons, but
we've broken it before by accident, and we'll break it again I'm
sure... I'm starting to question the value of binary compatibility and
(after we release 7.0 and my Xorg membership is approved..) I'm going
to submit a proposal to the arch working group with a list of good
reasons for not worrying about it too much in the future (I'm not
doing this now as it will generate a huge debate which will take too
much time away from the 7.0 release schedule...

> Is there any way this could be redone in a binary compatible fashion?
> For instance, leave the old functions, but tell everyone they are
> deprecated and add new functions with the domain arguments they should
> use instead?   The old functions could even simply be wrappers around the
> new that call the new ones with a domain of 0 or -1 or something.
> (For the ones called from drivers - those internal to the Xorg server
>   aren't as important to preserve.)

But why? I'd rather have clean code going forward than a codebase full
of backwards compatiblity hacks... that no-one understands in a year
or two...

being a slave to binary compatiblity generates an awful lot of ugly
twisted code, it is a *major* barrier to entry for new coders and
currently from what I can see is only there to help out a single
contributor and a whole host of non-contributing companies...

> 
> Also one other point in the patch I'm confused about: Why are you adding
> locking.c to Xprint?   Is that a workaround for the Xrm.c issues there
> that snuck into this patch accidentally?

dodgy patch in my tree.... I've a cleanup in bugzilla...

Dave.