[PATCH] Abstract calls to in/out with IN/OUT macros

[Adam Jackson]

On Sun, 2009-11-01 at 18:22 -0500, Matt Turner wrote:
> On Sun, Nov 1, 2009 at 6:13 PM, keithp <keithp at keithp.com> wrote:
> > Excerpts from Mark Kettenis's message of Sun Nov 01 13:19:04 -0800 2009:
> >
> >> While I sympathise with your attempt to clean up the mess in
> >> compiler.h, this will break at least one driver (xf86-video-i128).
> >
> > A fine example of why we want to merge the drivers into the server :-)
> >
> > In any case, for now, I'd rather see an ABI/API compatible change that
> > has the server get at the system io functions through a standard api
> > while still providing the old interfaces so that drivers continue to
> > build unchanged. Having those old interfaces work through the new
> > standard API would be great if possible. Marking those as 'deprecated'
> > so that the compiler emits a warning would be a nice bonus.
> 
> This would be nice, but I'm not sure how it could be possible, since
> in half the cases of OS/Architecture combinations, the drivers call
> the libc in/out, so no chance to warn. Then again, this is entirely
> the problem with the current 'API' if we can even call it that.

I'd like to suggest fixing this in pciaccess for real:

http://lists.x.org/archives/xorg-devel/2009-November/003255.html

I think the API given there is pretty much right, at least for I/O BARs.
There still remains the question of non-BAR I/O ports, ie, the VGA
space.  Maybe something like:

void *pci_nonbar_open_io_range(struct pci_device *dev, uint16_t port, uint16_t count);

I think you want to pass in the device, so if you've got multiple
domains you can get the legacy I/O map for the right domain.  There's
still some questions though:

- Should it refuse to open ports claimed by a PCI BAR?
- Should it refuse to open 0xCF8 / 0xCFC since we already have an API
  for PCI config space access?
- Are there any other ports it should refuse to open?

I think fixing up the drivers for the new API is a fairly small spatch
script per driver.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20091102/87c514f2/attachment.pgp