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.