From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 4 20:00:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F37716A421 for ; Wed, 4 Jul 2007 20:00:59 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id 036A113C455 for ; Wed, 4 Jul 2007 20:00:58 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l64JntwF013477; Wed, 4 Jul 2007 12:50:00 -0700 (PDT) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l64JntMv013476; Wed, 4 Jul 2007 12:49:55 -0700 (PDT) (envelope-from steve) Message-Id: <200707041949.l64JntMv013476@wattres.watt.com> X-Newsgroups: local.freebsd-hackers In-Reply-To: From: steve@Watt.COM (Steve Watt) References: <20070704091349.T42421@fledge.watson.org> Organization: Watt Consultants, San Jose, CA, USA Date: Wed, 4 Jul 2007 12:49:54 -0700 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: n.cormier@gmail.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (wattres.watt.com [127.0.0.1]); Wed, 04 Jul 2007 12:50:00 -0700 (PDT) X-Archived: 1183578600.225914010@wattres.Watt.COM Cc: freebsd-hackers@freebsd.org Subject: Re: p_vmspace in syscall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2007 20:00:59 -0000 In , Nicolas Cormier wrote: >On 7/4/07, Robert Watson 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...