From owner-freebsd-arch Wed Jan 22 19:43:46 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 AC58937B401 for ; Wed, 22 Jan 2003 19:43:44 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED59C43EB2 for ; Wed, 22 Jan 2003 19:43:43 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0N3hfbs044972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 22:43:41 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0N3hfXt044969; Wed, 22 Jan 2003 22:43:41 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 22:43:41 -0500 (EST) From: Garrett Wollman Message-Id: <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301230259.h0N2xt9R017635@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <200301230259.h0N2xt9R017635@apollo.backplane.com> 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 < said: > 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), No, SysV shared memory is emphatically not anonymous. It does not use the filesystem namespace, but it certainly does have a namespace, and every SysV shared memory segment has a name in that namespace. (A particularly badly thought-out one at that, which causes all sorts of resource leaks when programs terminate unexpectedly.) > 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 No, you haven't explained a damn thing. You haven't even stated the problem at all. Tell me, once and for all, WTF is wrong, technically, with the shm_open interface. Don't give me any NIH crap, I'm not interested in hearing your theories on technical elegance or what not. We have a standard interface. Given a lack of a clear problem statement, I can only conclude that the interface *can* do what you seem to be saying you want it to do (it was good enough for SSWG-RT), but that you are for some reason firmly attached to your pet interface instead. How the current implementation of shm_open() works is entirely irrelevant; my desire is to replace it. > 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. You claim to have already implemented it. I'm not interested in reinventing your work on the VM side of this. I just want to avoid public exposure of a proprietary interface when a standard interface would do the job just as well. > That's a terrible hack. I would never implement that. Why don't we make some more molehills into insurmountable obstacles? > I would far prefer to implement a > high-level operations vector on descriptors that covers both mmap() and > ftruncate() (at a high level), Great idea, you do that. I don't see it as a show-stopper; it is easy to recognize and undo the hacks later when a better implementation is ready. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message