On Fri, Jun 14, 2013 at 12:54:43PM +0200, Thomas Klausner wrote: > Hi Matthieu! > > > +#elif defined(PCI_MAGIC_IO_RANGE) > > > + ret->memory = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, > > > + aperturefd, PCI_MAGIC_IO_RANGE + base); > > > > Hmm where is aperturefd defined in the NetBSD case ? (I know it's is > > defined as static in openbsd_pci.c, but I can't find the similar hack > > for NetBSD > > That's a copy'n'paste error from openbsd_pci.c. PCI_MAGIC_IO_RANGE is > only defined for a few ports of NetBSD anyway, and neither me nor > Chuck know what the proper way to do this is. I guess I'll just remove > this #elif clause.
The idea behind PCI_MAGIC_IO_RANGE is to define a particular vm address where the kernel would map the I/O range of the card, so that inb/outb style functions in userland can access them, when the driver has no knowledge of explicit MMIO mappings. IIRC in NetBSD Michael Lorenz has fixed a number of drivers to do explicit MMIO in order to avoid the need for that hack. > > > -- and it should not be needed in NetBSD's case where all > > memory can be be mapped through the /dev/pci* entry). > > Can you please expand on this or suggest what the patch should look > like? > On OpenBSD we have the "aperture driver" which provides access to device memory through /dev/xf86 (instead of /dev/mem or the console device) and privilege separation in the X server. 'aperturefd' in openbsd_pci.c is a separate static variable holding the file descriptor for /dev/xf86, and is initialized by pci_system_init_dev_mem(), an OpenBSD specific libpciaccess function that is called early, while the X server still has root privileges, before calling pci_system_init(). On NetBSD you don't have that extra device to open and that extra file descriptor to keep, since the xserver is running as root and can open the /dev/pci* devices at will. So even in the PCI_MAGIG_IO_RANGE, you should use either the file descriptor for the current PCI bus or open /dev/mem explicitely in that mmap() call. While moving to KMS this is probably an area where we can clean up things and simplify them on OpenBSD, but for now we decided to get KMS working with minimal changes only. -- Matthieu Herrb _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
