From owner-freebsd-arch Wed Jan 22 13: 8: 1 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 044B937B401; Wed, 22 Jan 2003 13:08:00 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E94DA43E4A; Wed, 22 Jan 2003 13:07:58 -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 h0ML7w0i009590; Wed, 22 Jan 2003 13:07:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0ML7w7W009589; Wed, 22 Jan 2003 13:07:58 -0800 (PST) Date: Wed, 22 Jan 2003 13:07:58 -0800 (PST) From: Matthew Dillon Message-Id: <200301222107.h0ML7w7W009589@apollo.backplane.com> To: Robert Watson Cc: Peter Wemm , phk@FreeBSD.ORG, "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: 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 :Yeah, I have to admit I'm not thrilled by these prospects -- there are :lots of places in the kernel where we directly operate on the vnode w/o a :struct file, or the supporting device, etc. Implementing consistent :semantics would be daunting at best. : :One of the nice things about the current patch + rename to memfd system :call was the pure simplicity of it. It introduces one new type of object :created by a simple system call, and then a single operation on it, :mmap(). I recognize the benefits of explicit namespaces in IPC, of :course... : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects :robert@fledge.watson.org Network Associates Laboratories If we assume that some future system call (fattach-like) will provide us with generic namespace operations for special file descriptors, then the current proposed patch becomes extremely simple and couild also trivially be MFC'd to -stable before the release cutoff. It would be in-line with other system calls such as pipe() and socketpair(). It's a question only of what we should call it. memfd() or getmemfd()? I'm a little worried about namespace pollution with memfd(), so I would put forth 'getmemfd()' as a better syscall name. But I am not rabid about it. int getmemfd(off_t size, int flags) Obtain a mmap()able descriptor representing a VM object of bytes (size will be rounded up to the nearest page). Flags should be 0 for now but may be used in the future to implement wired and/or physical backing store, etc. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message