On 7/4/07, Robert Watson <[EMAIL PROTECTED]> wrote:
How much memory are we talking about -- enough to potentially run into kernel address space problems on 32-bit systems? How long will the mappings persist -- do you map them into kernel for a brief period to fill them, and then leave them mapped into user space, or is this going to be a persistent shared mapping over a very long period of time? Is the memory going to be pageable? How will it interact with things like mprotect(), msync(), etc? What should happen if a the pages are released by the process using munmap() or by mapping over the region with mmap()? What should happen in a child process if a process forks after netattach() and the parent calls netdatach()? What happens if the process calls send() using a source address in the memory region, and zero-copy sockets are enabled, which would normally lead the page to be "borrowed" from the user process?
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. -- Nicolas Cormier _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
