tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Implement mmap for PUD

> 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.

Home | Main Index | Thread Index | Old Index