Hello, On Tue, 3 Mar 2026 18:48:36 -0300 Oliver Miyar Ugarte <[email protected]> wrote:
> I've been working on the Userland PCI Drivers project for GSoC 2026 > (https://wiki.netbsd.org/projects/project/userland_pci/) and have a > draft implementation of the first milestone, achieved by mapping PCI > BARs from userspace via a new ioctl. > (https://github.com/NetBSD/src/pull/74) > > This adds PCI_IOC_MAP_BAR to /dev/pci/pci_usrreq.c, allowing userspace > to safely map device registers without using /dev/mem. I've tested it > with QEMU's edu device and it returns the correct BAR offset and size. You can already map PCI resources by their bus addresses via /dev/pci*, and access config space via ioctl(PCI_IOC_BDF_CFG{READ|WRITE}). That's what the Xserver uses. See https://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/libpciaccess/dist/src/netbsd_pci.c?rev=1.23 and https://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpci/ What's missing is stuff like DMA and interrupts from userland. No idea why the project proposal mentions /dev/mem at all - it's not portable ( there's a lot of supported hardware where PCI bus addresses do not map 1:1 to physical addresses in CPU space, and others where you can only see actual RAM through /dev/mem, not PCI space ) and requires knowledge of the underlying hardware other than the device you're trying to talk to. So, why the additional ioctl? You can already access config space, find devices and their BARs, and mmap() them at offset == bus address without any kernel changes. have fun Michael
