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. -- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
