From owner-freebsd-arch Wed Jan 22 20:16:57 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 5590537B401 for ; Wed, 22 Jan 2003 20:16:55 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA28D43ED8 for ; Wed, 22 Jan 2003 20:16:54 -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 h0N4Gn0i017990; Wed, 22 Jan 2003 20:16:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0N4GnRv017989; Wed, 22 Jan 2003 20:16:49 -0800 (PST) Date: Wed, 22 Jan 2003 20:16:49 -0800 (PST) From: Matthew Dillon Message-Id: <200301230416.h0N4GnRv017989@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> <200301230259.h0N2xt9R017635@apollo.backplane.com> <200301230343.h0N3hfXt044969@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 :> 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. Did you even bother reading any of my prior postings? Fine then, I'll explain it again, for the fourth time. We need a shared memory mechanism that is swap-backed. It's that simple. I'll repeat it. For the Fifth time: We need a shared memory mechanism that is swap-backed. Understand the problem now? shm_open() as it currently stands does not in any way give us the above. Now, I think I understand what you are getting at. You seem to believe that implementing shm_open() in the kernel is the solution. There's a serious problem with doing this, however. Actually, there are two problems with doing this: (1) We don't have the kernel infrastructure to support it without a lot of hacks. i.e. we need a file-descriptor based vector array for high level descriptor based system calls in order to implement shm_open() properly in the kernel if we want to have any hope of keeping it compatible, or growing its compatibility, with other implementations. (2) You are talking about a fairly complex API in its full glory. In its full glory shm_open() needs to deal with both private and public name spaces. Implementing this in the kernel makes very little sense to me when the same thing can be implemented in userland at a far lower cost and far lower complexity. Hence, the current proposal is to implement a far simpler system call, one that simply returns a memory descriptor. This far simpler system call can eventually be leveraged in the userland implementation of shm_open(), at a far lower development cost. For example, Peter brought up the idea of using the solaris fattach() and related system calls as a means to give a memory descriptor public namespace support, and private namespace support can just as obviously be implemented within libc. As has been already discussed, some of the aspects of shm_open() do not lend themselves well to kernel implementation -- namely the private namespace support. In a previous email you seem to reject the whole concept of a private namespace but you can't argue that and also argue that we should implement it in the kernel, because then we wind up with a non-standard implementation of a standard's based function name. Now if you, personally, are willing to put in the huge amount of work necessary to implement shm_open(), in its full glory, in the kernel, I think that's just dandy. But if you aren't (and in your previous emails you don't seem to be willing to follow the shm_open() API in its full glory in a kernel implementation), then I don't see any advantage to regressing our shm_open() interface and instead I would far rather implement the simpler interface in the kernel and then, once we get all the proper support in down the line, use it to back a fully implemented userland shm_open(). I am recommending a course of action that allows us to incrementally achieve the same goals at a far lower cost. You seem to be trying to force a course of action, which you are not willing to undertake yourself, which achieves the goals at far higher cost, complexity, and with more hacks to the kernel. I'm sorry if you don't agree with me but that is my take on the situation. I really dislike hacking random code in the kernel unless its absolutely necessary. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message