This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: named anonymous vmas
- From: Christoph Hellwig <hch at infradead dot org>
- To: Colin Cross <ccross at google dot com>
- Cc: Christoph Hellwig <hch at infradead dot org>, lkml <linux-kernel at vger dot kernel dot org>, Linux-MM <linux-mm at kvack dot org>, Android Kernel Team <kernel-team at android dot com>, John Stultz <john dot stultz at linaro dot org>, libc-alpha at sourceware dot org
- Date: Thu, 1 Aug 2013 01:29:51 -0700
- Subject: Re: RFC: named anonymous vmas
- References: <CAMbhsRQU=xrcum+ZUbG3S+JfFUJK_qm_VB96Vz=PpL=vQYhUvg at mail dot gmail dot com> <20130622103158 dot GA16304 at infradead dot org> <CAMbhsRTz246dWPQOburNor2HvrgbN-AWb2jT_AEywtJHFbKWsA at mail dot gmail dot com>
Btw, FreeBSD has an extension to shm_open to create unnamed but fd
passable segments. From their man page:
As a FreeBSD extension, the constant SHM_ANON may be used for the path
argument to shm_open(). In this case, an anonymous, unnamed shared
memory object is created. Since the object has no name, it cannot be
removed via a subsequent call to shm_unlink(). Instead, the shared
memory object will be garbage collected when the last reference to the
shared memory object is removed. The shared memory object may be shared
with other processes by sharing the file descriptor via fork(2) or
sendmsg(2). Attempting to open an anonymous shared memory object with
O_RDONLY will fail with EINVAL. All other flags are ignored.
To me this sounds like the best way to expose this functionality to the
user. Implementing it is another question as shm_open sits in libc,
we could either take it and shm_unlink to the kernel, or use O_TMPFILE
on tmpfs as the backend.