> It is called pipe(2), isn't it? Thanks for the reply, but I don't understand why pipe could be helpful in this situation, the mmap kernel call needs to return a paddr_t (a memory region), and pipe returns a pair of file descriptors, that I cannot pass to the kernel. The flow of a PUD call is something like:
1. Program A makes a mmap call to a char device. 2. The kernel PUD driver handles the call and passes it to the userspace daemon that registered the device. 3. The userspace PUD daemon allocates a memory region and returns the address to the kernel PUD driver. 4. The kernel PUD driver translates the address to a physical direction and returns it to program A. 5. Program A receives the memory region. I have archived most of this process, but I think the memory used to return the call should be marked as shared somehow, or locked, because I get the kernel panic described in a previous message, even when trying to lock the memory with uvm_vslock. I don't know if it's possible to return a memory address allocated from userspace in a mmap kernel implementation. Regards, Roger.
