p_vmspace in syscall

[Steve Watt]

In <c4630b800707040200n4a6de4f5j2008f60fefb149e6 at mail.gmail.com>,
  Nicolas Cormier <n.cormier at gmail.com> wrote:
>On 7/4/07, Robert Watson <rwatson at 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.

-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.5" / 37N 20' 15.3"
 Internet: steve @ Watt.COM                      Whois: SW32-ARIN
   Free time?  There's no such thing.  It just comes in varying prices...