OK, I've re-read this topic. Your goal is to implement blktap on NetBSD/Xen, right?
According to Xen wiki [1], blktap provides an interface for userland to handle block device I/O. I guess blktap gets inter-domain, shared ring memory from hypervisor. Dom0 userland mmaps the ring memory and handles I/O requests. pud(4) is different; it pretends a device driver backed by a real H/W. Kernel passes buffers to pud(4) so that pud(4) can read/write data from/to a real H/W, either PIO or DMA. PIO uses kernel address space to access passed buffers. DMA uses physical addresses. Here you want to mmap those buffers to userland, right? I don't think it's possible. Underlying pages of given buffers are marked "busy doing I/O" (PG_BUSY). Users (either vnode/anon owners) are not allowed to map those pages until I/O completes. If some pud(4) backend driver process suddenly tries to mmap those pages, VM will surely get upset. So a possible blktap(4) would look like: - run only in Xen Dom0 - allocate (map) shared ring memory (both I/O requests and buffers) from hypervisor using Xen machine-dependent API - convert blktap I/O requests to NetBSD's bdev/strategy/struct buf format - and call pud(4) in kernel ? [1] http://wiki.xensource.com/xenwiki/blktap