On Sun, 2009-11-01 at 18:22 -0500, Matt Turner wrote: > On Sun, Nov 1, 2009 at 6:13 PM, keithp <[email protected]> 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
