Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jul 2007 15:04:19 +0200
From:      "Nicolas Cormier" <n.cormier@gmail.com>
To:        "Robert Watson" <rwatson@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: p_vmspace in syscall
Message-ID:  <c4630b800707040604r296632dap562f6e6bc0bfe330@mail.gmail.com>
In-Reply-To: <20070704120624.W37059@fledge.watson.org>
References:  <c4630b800707020954s4aa0be68t2d5f3eb864f2dda5@mail.gmail.com> <20070704091349.T42421@fledge.watson.org> <c4630b800707040200n4a6de4f5j2008f60fefb149e6@mail.gmail.com> <20070704120624.W37059@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7/4/07, Robert Watson <rwatson@freebsd.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c4630b800707040604r296632dap562f6e6bc0bfe330>