start of some pci cleanups

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michel Dänzer wrote:
> On Tue, 2005-07-26 at 09:11 +1000, Dave Airlie wrote: 
> 
>>>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...
> 
> 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."

> and my impression is that it resulted in more people trying the latest
> code and providing valuable feedback. It also allowed to mix'n'match
> components during development instead of having to ensure they're in
> lock-step.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC5qX3X1gOwKyEAw8RAh+vAKCR7owFGHeFd2ZvvPMbnPQNB//lugCff1Fd
gKZp3khwoMDQZE9r1Rf+jRY=
=Oj/J
-----END PGP SIGNATURE-----