Re: p_vmspace in syscall


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