Hi! Michael <[email protected]> wrote: > > 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
Thanks a lot for the feedback! I can't believe I missed that existing infrastructure, I had tunnel vision on doing what the project proposal mentioned and didn't check sufficiently if it already existed. I will focus my project on adding DMA and interrupts to userland since that's what's needed. Do you have any advice on that? Well wishes! Oliver Miyar Ugarte
