Date: Wed, 22 Jan 2003 13:07:58 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Peter Wemm <peter@wemm.org>, phk@FreeBSD.ORG, "Alan L. Cox" <alc@imimic.com>, arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301222107.h0ML7w7W009589@apollo.backplane.com> References: <Pine.NEB.3.96L.1030122065201.47551B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 <size> 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301222107.h0ML7w7W009589>