Date: Wed, 4 Jul 2007 22:00:48 +0200 From: "Nicolas Cormier" <n.cormier@gmail.com> To: "Steve Watt" <steve@watt.com> Cc: freebsd-hackers@freebsd.org Subject: Re: p_vmspace in syscall Message-ID: <c4630b800707041300w632263eco9e61145e8c46318b@mail.gmail.com> In-Reply-To: <200707041949.l64JntMv013476@wattres.watt.com> References: <c4630b800707020954s4aa0be68t2d5f3eb864f2dda5@mail.gmail.com> <20070704091349.T42421@fledge.watson.org> <c4630b800707040200n4a6de4f5j2008f60fefb149e6@mail.gmail.com> <200707041949.l64JntMv013476@wattres.watt.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/4/07, Steve Watt <steve@watt.com> wrote: > In <c4630b800707040200n4a6de4f5j2008f60fefb149e6@mail.gmail.com>, > Nicolas Cormier <n.cormier@gmail.com> wrote: > >On 7/4/07, Robert Watson <rwatson@freebsd.org> wrote: > >> > >> When operating in a system call, the 'td' argument to the system call function > >> is the current thread pointer. You can follow td->td_proc to get to the > >> current process (and therefore, its address space). In general, I prefer > >> mapping user pages into kernel instead of kernel pages into user space, as it > >> reduces the chances of leakage of kernel data to user space, and there are > >> some useful primitives for making this easier. For example, take a look at > >> the sf_buf infrastructure used for things like socket zero-copy send, which > >> manages a temporary kernel mapping for a page. > >> > > > >netmalloc syscall does something like that: > >- query distant host to allocate size > >- receive an id from distant host > >- malloc in kernel size > >- map the buffer to user process (*) > > > >netdetach syscall: > >- send data to distant host > > > >netattach syscall: > >- get data from host > >- malloc in kernel size > >- map the buffer to user process (*) > > What this really sounds like is network shared memory or remote DMA. > I would architect this to remove as much of the management code as > possible from the kernel (i.e. query the distant host, get ID, etc.) > into a userland daemon. Depending on the exact semantics you want, > you'll probably need to write a new kind of pager. > > Basically, at the netmalloc call, you would simply pass the reqest > back to the userland daemon, which would format it in whatever way is > needed to cross the net, send the request off, receive the ID, and > give association information back to the kernel (number of pages, > protections, whatever). Then the call would map the new pages into > the userland process just like it was a shared memory segment. > > At detach time, the message would again go to the userland daemon, > which would map the pages locally and probably use a zero-copy send > to ship the data to the remote host. > > There are some fun potential interactions in there in code I haven't > looked at in a long time. I'll resist the urge to dive in and hack > something together, since VM systems have a way of being tricky in > unexpected places. Thank you for this post ! Your design should be a good start. -- Nicolas Cormier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c4630b800707041300w632263eco9e61145e8c46318b>