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

[Luc Verhaegen]

On Thu, Nov 19, 2009 at 11:53:16AM -0500, Adam Jackson wrote:
> On Thu, 2009-11-19 at 00:37 +0100, Luc Verhaegen wrote:
> 
> > And i just keep on wondering... Just like with the VGA arbitration... 
> > Didn't the RAC used wrap all this crap for us _outside_ calls to driver 
> > code so that we could just access IO and memory directly, without 
> > having to care at all?
> 
> RAC did not handle this correctly when multiple X servers were running;
> VGA arb does.  The I/O port routines in the server - not strictly part
> of RAC - leave the onus of domain safety on the driver, and are a
> wretched pile of ifdef (though admittedly a working pile).
> 
> The deeper assumption with RAC was that the OS could not be trusted to
> give you a working PCI memory map, and that it was okay to rewrite it.
> No no no no no.

This was not just RAC, this was just the situation of that time.

Now, my understanding of RAC, from a driver point of view, was that you 
provided it with some information as to what resources your hardware 
needed, and it would then magically take care of everything for you, 
before you entered any driver specific call, so you never had to worry 
about it then.

Afaik, instead of fixing up the backend, this nice infrastructure was 
entirely removed.

Because this is really what i care about, as long as it is all behind 
the scenes, and it has no consequences for me as a driver developer, and 
it works (without making the mistakes that old solutions fixed), i am 
happy.

Look at this code, it is so close to RAC like behaviour already. There 
is code to enable and disable io access. Why can we not use IN/OUT[BWL] 
macros in between like before? Why can enable/disable not wrap driver 
calls like RAC before?

The baby was thrown out with the bathwater with libpciaccess and vga 
arbitration, and now suddenly the plan seems to be to put these new 
enable/disable hooks all over the driver, together with slightly more 
involved IN/OUT calls.

Unacceptable.

> > How hard would it have been to have written up a 
> > backend for the RAC for the linux pci code that popped up during the 
> > active life of RAC? My guess is, much easier than the stuff that has to 
> > be pulled now, all it took was that someone was willing to go into 
> > existing code and understand how it work(s/ed).
> 
> The Linux PCI code did use RAC.  I don't know why you think it didn't?
> 
> As someone who's actually had to fix bugs in the PCI code in 6.8:
> while: 
> 
> - the transition to the new library was ungraceful
> - the motivation for switching was a complete MacGuffin
> - the internal conversion to pciaccess is still incomplete, and
> - the completion of VGA arbitration took embarassingly long
> 
> I can honestly and without reservation say that the current code is
> comprehensible and pleasant to work with, and the old PCI layer has
> literally woken me from sleep sweating in terror.

Of course it is, today we can depend on operating systems have useful 
pci support. Not so then.

But there is nothing that stopped people from keeping the upper level 
infrastructure in place while having reworked the backend to work on top 
of the now existing nice pci support in the kernel. The only reason 
to replace the whole thing was rampant NIH.

And this rampant NIH is the core cause for the big nasty interface 
change and RAC being #ifdeffed and commented out, without a replacement, 
for several years.

> > Oh, and that's before i start wondering about gratuitous void pointers 
> > and goto.
> 
> The handle needs to be opaque to the user, because it's intrinsically
> platform-dependent.  Kristian's opaque struct name suggestion is
> probably what I'll go with.

Ah, good, typechecking will still happen then. Thanks.

Luc Verhaegen.