On Tue, Jan 28, 2014 at 10:05 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: > On 01/28/2014 01:01 PM, Kay Sievers wrote: >> On Tue, Jan 28, 2014 at 9:58 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: >>> On 01/28/2014 12:37 PM, H. Peter Anvin wrote: >>>> On 01/28/2014 11:56 AM, John Stultz wrote: >>>>> Thanks for reminding me about O_TMPFILE.. I have it on my list to look >>>>> into how it could be used. >>>>> >>>>> As for the O_TMPFILE only tmpfs option, it seems maybe a little clunky >>>>> to me, but possible. If others think this would be preferred over a new >>>>> syscall, I'll dig in deeper. >>>>> >>>> What is clunky about it? It reuses an existing interface and still >>>> points to the specific tmpfs instance that should be populated. >>> It would require new mount point convention that userland would have to >>> standardize. To me (and admittedly its a taste thing), a new >>> O_TMPFILE-only tmpfs mount point seems to be to be a bigger interface >>> change from an application writers perspective then a new syscall. >>> >>> But maybe I'm misunderstanding your suggestion? >> 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? Right, general purpose Linux could not mount with that option without expecting major breakage, see: man shm_overview. But a custom OS could just define that, I guess. The current /dev/shm/ semantics and the shm apis in general are a kind of a broken idea from the very beginning. Kay -- 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>