start of some pci cleanups

[Keith Whitwell]

>>>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...
>>
>>I have quite a different stance on backwards compatibility. I think it
>>should be preserved whenever reasonably possible. And I'm not saying
>>that primarily as someone who gets paid to work on binary-only drivers
>>but as someone who has been spending a lot of time working on and
>>supporting free drivers. I'm quite disturbed that apparently many if not
>>most of the current contributors to the DRI project no longer care about
>>backwards compatibility. We used to go to great lengths to preserve it,
> 
> 
> We did used to go to great lenghts.  In fact, quite a few people spent a
> *LOT* of time working on maintaining backward compatiblity instead of
> doing "useful" work.  I'm not saying that we should be sloppy and break
> things whenever we're feeling lazy.  However, I am saying that carrying
> around *1,500* lines of code that only one or two people understand
> purely to maintain dead internal interfaces is absurd.
> 
> We just don't have enough resources to allocate developer time in that way.
> 
> I also feel that compatibility breaks should be done in a way that is
> clear to users.  Having things crash or emit obscure messages doesn't
> cut it.  If we can detect that some component is too old, the user
> should get a message "Component FOO is too old.  Upgrade."

Another thing that has changed over the years is the emergence of proper 
dependency tracking in the distributions where the above upgrade can be 
done automatically for many components.  This doesn't remove all 
responsibility for compatibility from us, but hopefully gives us a 
little more wiggle room when things finally need to change.

Keith