[PATCH 2/2] I/O port access routines

[Luc Verhaegen]

On Thu, Nov 19, 2009 at 06:36:15PM +0200, Tiago Vignatti wrote:
> 
> PCI code was removed (well, it's being) from X and needed be put somewhere.
> libpciaccess was the name of the place. I can imagine how tied and coupled
> such code was with the rest of the server and it was more easy to just
> reimplement some parts. So, it was a decision that someone made. 
> 
> But the removal of PCI from X was not all the problem; there was also RAC
> which, as I said to you, should be visible from other apps. Given, recently
> kernels are already doing a lot of RAC's job, we decided to just call another
> name - VGA arbiter - and implement only the necessary parts.
> 
> 
> I don't see why you're complaining so much...
> 
> 
>             Tiago

Oh man... This whole logic, when looked at it by a driver developer who 
just wants to have his driver work, is soo interdependent.

Current situation:
* We have to wrap io calls in the driver.
* Why?
* Because we threw out RAC completely.
* Why?
* Because we no longer had VGA arbitration.
* Why?
* Because we daftly threw out the old xserver pci code completely and 
  reinvented it, and didn't bother to keep existing APIs nor give RAC
  support for this new backend code.
* Why did we throw out old pci code?
* Because the lowlevel code was involved and was not using the operating 
  system infrastructure that popped up "recently".
* Why do it that way?
* Because it's just how we did it, ok? now stfu.

Now i am sure that i am not the only person who frowns upon the logic 
applied in there, when it is, finally, laid out like this.

And Tiago, it was not coupled that tightly. It supported just about 
every operating system out there at the time (in as far as it supported 
operating systems itself), and the driver side interface was not 
fundamentally different from what we have now. For reference, you can go 
and check any driver that has the compat code.

Code is mostly different for the sake of being different. NIH.

Luc Verhaegen.