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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
