From owner-freebsd-arch Wed Jan 22 18:59:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9242037B405 for ; Wed, 22 Jan 2003 18:59:56 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C45743E4A for ; Wed, 22 Jan 2003 18:59:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0N2xt0i017636; Wed, 22 Jan 2003 18:59:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0N2xt9R017635; Wed, 22 Jan 2003 18:59:55 -0800 (PST) Date: Wed, 22 Jan 2003 18:59:55 -0800 (PST) From: Matthew Dillon Message-Id: <200301230259.h0N2xt9R017635@apollo.backplane.com> To: Garrett Wollman Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> Moving shm_open() to kernel space? That's a pretty tall order. I :> don't think anyone has proposed that until now. : :It was always my expectation that this would happen at some point. You are welcome to try, but I would consider it a big mistake. :> I would argue that namespace private operations are far better handled :> in userspace then kernelspace (why waste kernel memory managing :> private namespaces?). : :Private namespaces are bad and unnecessary. We already have anonymous :shared memory; I don't see any need for ``semi-anonymous'' shared :memory. The garbage-collection problem is already bad enough. I have no idea what you are talking about here. We can do swap-backed anonymous shared memory using SysV shared memory (non descriptor-based), and we can emulate anonymous shared memory using shared files (descriptor based), but we have no descriptor-based shared memory mechanism that uses swap backing store and that is primarily what most people need when they need shared memory. These are not minor differences. It is a huge problem to people who use shared memory regularly like Peter, and me as well. I had to go through loops to make shared memory work in the Diablo news system and I sure wish I had getmemfd() back then! :You haven't provided any justification that I've seen for introducing :a new interface when the one we've got can already do that. We have no interface that has any capability to do what we want. I've explained to you what the problem is several times now in exruciating detail and you have ignored me every time, disputing the conclusion without providing anything to back up your assertion. I am going to explain again in the next sentence: We have no descriptor-based shared memory mechanism which uses swap as backing store. It's that simple. If you believe that such a mechanism already exists then, by all means, tell us all what it is. :> To do that requires a two-stage process of which my current proposed :> patch is only stage-1, since we have no current ability to call :> ftruncate() on a descriptor, only a vnode. : :Trivial under my proposal... here's the conceptual patch: That's a terrible hack. I would never implement that. It's bad enough that mmap() has to be hacked. I would far prefer to implement a high-level operations vector on descriptors that covers both mmap() and ftruncate() (at a high level), not add more low level hacks. I believe it makes sense to hack mmap() in the proposed stage-1 patch, but that's about as far as I am willing to go. The next step would be a high level operations vector. Again, I have reiterated the technical details of the problem and the proposed solution. If you believe a solution is possible without adding another system call I'm all ears. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message