

Memfd_create() syscall merged into Linux tree - joshbaptiste
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9183df25fe7b194563db3fec6dc3202a5855839c
Blog post on memfd 
https:&#x2F;&#x2F;dvdhrm.wordpress.com&#x2F;tag&#x2F;memfd&#x2F;
======
joshbaptiste
Blog post on memfd
[https://dvdhrm.wordpress.com/tag/memfd/](https://dvdhrm.wordpress.com/tag/memfd/)

------
comex
So previously there was a new syscall to replace /dev/urandom in cases where
it can't be accessed, and now there's one to replace /dev/shm?

I know there are good practical reasons for both changes, but it seems like
sandboxing is throwing the baby out with the bathwater a little bit. ;P

~~~
saurik
No: this API is fundamentally different from /dev/shm, and will hopefully
obviate the need for some Android-specific patches (such as ashmem, though
ashmem may already have been replaced by a new flavor of the week). /dev/shm
is a folder, which represents a global namespace of memory objects, and which
essentially must be manually reclaimed (imagine a world where you create an
object, and then kill -9 the app before immediately uninstalling it). This API
has a name, but it is for debugging purposes only: the lifetime and
accessibility of the object is based purely on the Unix semantics of memory
maps and file descriptors (which can be laterally shared using Unix domain
sockets), allowing them to be automatically cleaned up. There is an additional
advantage that it works without extra mount points, but I doubt that would
have been a sufficient motivation for this change: /dev/shm is so problematic
that it doesn't even exist on Android.

~~~
swetland
ashmem is still in use. This comes close to doing everything ashmem does, but
is missing the pin/unpin mechanism, where a process can indicate pages that
the system may reclaim if it needs the memory (and later attempt to pin them
again to discover if they still exist or not).

