On 01/28/2014 01:10 PM, H. Peter Anvin wrote: > On 01/28/2014 01:05 PM, John Stultz wrote: >>> General purpose Linux has /dev/shm/ for that already, which will not >>> go away anytime soon.. >> Right, though making /dev/shm/ O_TMPFILE only would likely break things, no? > If it isn't, then you already have a writable tmpfs, which is what you > said you didn't want. Well, rather then finding a solution exclusively for Android, I'm trying to find an approach that would work more generically. While classic Linux systems do have writable /dev/shm/, which we *have* to preserve, it seem to me that classic linux systems may some day want to deal with the issues with writable tmpfs that Android has intentionally avoided. For examples of grumblings on these issues see: https://bugzilla.redhat.com/show_bug.cgi?id=693253 (and its dup) Requiring a binary on/off flag for /dev/shm makes it so you have to choose if you are a classic or new-style (android-like) system. By avoiding re-using existing convention via providing a new syscall (or alternatively with your approach, a new yet to be standardized mount point convention), it would allow best practices to be updated, and allow for a slow deprecation of the writable /dev/shm, possibly by limiting permissions to /dev/shm to only legacy applications, etc. But yes, alternatively classic systems may be able to get around the issues via tmpfs quotas and convincing applications to use O_TMPFILE there. But to me this seems less ideal then the Android approach, where the lifecycle of the tmpfs fds more limited and clear. And my main point being: Both Android's ashmem and kdbus' memfds are both utilizing these semantics (though maybe they aren't as important/intentional for kdbus?), so it seems like some generic method (which would work in both environments) would generally useful. Again, I really do appreciate your feedback here, and I don't mean to be panning your idea (I'm quite willing to look further into it if others think its the right way)! I just want to explain my point of view and motivations a bit better. thanks! -john -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>