On 12/15/2010 06:40 AM, Matthew Miller wrote:
On Tue, Dec 14, 2010 at 10:19:38PM -0800, John Reiser wrote:
> Also, the claim "The API for /dev/shm is shm_open()" is incorrect.
> See the other message for the history. When something is in the file
> system, then by default the file system APIs (including creat, open,
> read, write, close, execve, dlopen, ...) are legitimate uses.
> (Originally [System V] shared memory was *not* in the file system,
> and this caused problems.)
I think you're confusing two things here. POSIX shared memory objects are
implemented on Linux using a tmpfs filesystem mounted at /dev/shm.
A file system usually supports creat, open, read, write, getdents, execve,
mmap(,,PROT_EXEC,,,), etc., and should expect those calls to be used by
any process that has access permissions. It's quite hard and cumbersome
to manipulate and administer shared memory objects using only shm*() routines
and without file system facilities such as directories, file names, ownership,
access permissions, etc., as illustrated by the history of System V shared
memory objects.
I don't think there's a particularly good reason to use that
filesystem for
other uses. Just mount another tmpfs elsewhere.
mount() requires CAP_SYS_ADMIN and therefore an application cannot rely
on performing mounts. A major point of this thread is that an application
wants to rely on using a file system that is present on all boxes, can be
accessed without special permissions or capabilities, and offers very
fast performance for small numbers of small-to-medium-sized files.
/dev/shm was the best choice until systemd in Fedora 15 rawhide mounted
/dev/shm with MS_NOEXEC. Even the preview edition of Ubuntu 11.04
omits the MS_NOEXEC.
--