On Tue, Apr 12, 2011 at 10:08:30PM +0200, Tollef Fog Heen wrote: > ]] Roger Leigh > > | I think that if we have /run/lock, /run/shm makes sense (how different > | are locks and POSIX semaphores? They are just a different type of > | lock (broadly). And shared memory is ephemeral state, just like > | samba's state etc.). So I would argue that it does fit. But this > | isn't a universally held opinion. Is there any rationale against > | doing this? > > /dev/shm is POSIX shared memory, not just semaphores, afaik? Yes, it's used for both. > | I'm not as sure about /run/tmp, though all the files under /run > | are strictly temporary, they are pretty much all system files > | rather than being owned by users (though /run/lock and /run/shm > | would be user-writable; however, there are proposals to restrict > | access to /lock as on Fedora). > > I'd rather not make /tmp a tmpfs, and there's no reason for it to live > under /run. It might also reasonably be namespaced for different users > and so on, so moving it somewhere else than /tmp is, IMO, silly. One reason for doing this is to have a single writable mount on the system, which might be useful for tiny systems with minimal resources, where root is r/o. On such a system, it might be useful to pool the limited writable space (which might not be a tmpfs). This isn't a common use case, but one of the considerations in the patch is to make read-only root possible, and since one of the changes is to automatically mount a tmpfs on /tmp if root is read-only, I thought it was worth asking the question if it could be shared with the existing tmpfs filesystems on the system. While a tmpfs on /tmp isn't going to be the default, the patch does add support for it (RAMTMP). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature