From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 4 20:00:50 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 0B31716A400 for ; Wed, 4 Jul 2007 20:00:50 +0000 (UTC) (envelope-from n.cormier@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id BD91F13C44B for ; Wed, 4 Jul 2007 20:00:49 +0000 (UTC) (envelope-from n.cormier@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so4499641pyb for ; Wed, 04 Jul 2007 13:00:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lEpqp9mc/4oATJyBx8tGuhAhoPNM28dzblI1vkNubm2h7CcQEyScps/FSEb3PkzHlturRBE8qQvV+/9TU0oNsMVNfKWrSQSfzvbLBuTHHeTv9VyNRFcQMwdsbtVJrjassBB94yjJTwed2UPQ5AsoPn3BrX7KiMrG8ajhyVjOkcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BJ6imrBmVa0m8mewGxQLCi/9sfzhbHebRAKKfTdWt68F+RU7U7kd4Bsw4iE5ShsJDHModAf4omzRyTRNNyvz8TOVIVtjLQaXmQ5Sq2o0LFtuBLvIOpq/0FDnbfdpf7nxkcXFLTkHlDxq8j3J09IVCPM/5CPP4N4xvK6lDbMagGo= Received: by 10.35.101.1 with SMTP id d1mr10300085pym.1183579249049; Wed, 04 Jul 2007 13:00:49 -0700 (PDT) Received: by 10.35.40.11 with HTTP; Wed, 4 Jul 2007 13:00:48 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 22:00:48 +0200 From: "Nicolas Cormier" To: "Steve Watt" In-Reply-To: <200707041949.l64JntMv013476@wattres.watt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070704091349.T42421@fledge.watson.org> <200707041949.l64JntMv013476@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:50 -0000 On 7/4/07, Steve Watt wrote: > 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. Thank you for this post ! Your design should be a good start. -- Nicolas Cormier