p_vmspace in syscall

[Robert Watson]

On Wed, 4 Jul 2007, Nicolas Cormier wrote:

> Currently I'm just trying to play with kernel/modules/vm ... I'm a newbie in 
> kernel development and I just want to make a little prototype of an 
> in-kernel network allocator. To start I only need to map a page (1024 bytes) 
> from kernel to user process. This memory will never be used by the kernel 
> between the call of net(malloc/attach) and the call of net(detach/free). So 
> user and kernel will never use this page at the same time.
>
>> The underlying point here is that there is a model by which VM is managed 
>> -- pages, pagers, memory objects, mappings, address spaces, etc.  We can't 
>> just talk about pages being shared or mapped, we need to think about what 
>> is to be accomplished, and how to map that into the abstractions that 
>> already exist. Memory comes in different flavours, and generally speaking, 
>> you don't want to use pages that come from malloc(9) for sharing with 
>> userspace, so we need to think about what kind of memory you do need.
>
> Thank you for your answer. Right now, I just want to do it as easily as 
> possible, I don't know if this kind of project could interest other persons 
> ? It is ok for me to work more on it later on, if there is any further 
> interest in doing it.

What do you mean by a network allocator?  How do you plan to use these pages?

If you haven't already, you should look at the zero-copy socket code in 
uipc_cow.c.  The main criticism of this approach has been that it uses 
copy-on-write, leading to potential IPIs for VM shootdowns, etc.  An 
alternative, more along the lines of IO-Lite, would be to allow user space to 
explicitly abandon the page on send, then map a new page to replace it.  In 
which case you might consider a variation on the send system call that accepts 
only page-aligned arguments and has the effect of unmapping the pages that are 
sent.  In neither case, on the transmit side, does this require an 
modification to the kernel memory allocator.

The receive side has always been more tricky to deal with...

Robert N M Watson
Computer Laboratory
University of Cambridge