In <[EMAIL PROTECTED]>, Nicolas Cormier <[EMAIL PROTECTED]> wrote: >On 7/4/07, Robert Watson <[EMAIL PROTECTED]> 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... _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
