On 01/11/15 13:13, Robert Millan wrote:
I read that Rump design is against implementing memory management within the rump kernel. Is this the reason for not providing rump_sys_mmap?
Yes, plus rump kernel system calls are supposed to work remotely where the callers and callee do not have access to the same memory. For mmap that does not hold. And, frankly, I think mmap goes in the same bin with e.g. scheduler activations: great idea in theory, but in reality adds ridiculous amounts of complexity to the implementation. Another way to think about mmap is like cut in prolog or set! in scheme: everything is nice and conforming, and then some rotten egg waltzes in.
I don't need memory management, just want rump_sys_mmap() in order to access the rump audio_mmap() of audio(4), which I expect will give me a direct pointer to the DMA-friendly memory allocated by rumpcomp_pci_dmalloc() in pci-userspace module.
Now that said, those rotten eggs were (usually) added for a reason. Do you have some really strong reason with experimental evidence for wanting mmap? Implementing rump_sys_mmap would require a bunch of code just to get the call down to the right place, where it would, like you suspect, do nothing or fail :/
I wonder if there's a better solution than providing a false promise of mmap and adding a ton of code.
