Re: [RFC] shmgetfd idea

[John Stultz <john.stultz@linaro.org>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>