Marc-André Lureau <marcandre.lur...@gmail.com> writes: > Hi > > On Wed, Mar 9, 2016 at 9:59 PM, Markus Armbruster <arm...@redhat.com> wrote: >> The integrated memory backend has to go. >> >> Yes, my desugaring to memory-backend-file assumes Linux and the >> conventional mount point /dev/shm. >> >> For what it's worth, glibc implements shm_open() as a thin wrapper >> around open() on all targets. On Linux, it looks for other mountpoints >> when /dev/shm/ isn't there or unsuitable. On other targets, it always >> uses /dev/shm/. I didn't bother to duplicate glibc's mountpoint search, >> because distros converged to /dev/shm/ long ago. >> >> The proper way to support POSIX shared memory objects on systems where >> they're not files (and therefore can't be mapped with >> memory-backend-file) is to create memory-backend-shm. If such systems >> exist. >> >> I didn't do this now, because one, I'm not aware of a system that needs >> it, and two, ivshmem is Linux-specific anyway. ivshmem-plain could be >> made more portable, and once that's done, memory-backend-shm might >> become useful. > > How is ivshmem (the "plain" part) Linux-specific? Afaik it works on bsd too.
To make ivshmem-plain more portable, either add suitable #ifdefs to ivshmem.c or split ivshmem-plain off into its own file. As is, we only compile ivshmem.c with CONFIG_EVENTFD. If someone does that work, *and* any of the systems opened up by that can't do use memory-backend-file, then those systems would profit from memory-backend-shm. >> That leaves permissions. You're right, the patch changes them from 0777 >> to 0644. I'm inclined to call it a bug fix. I failed to mention it in >> my commit message, and I'll fix that. We may want to mention it in >> release notes, too. > > That's good enough for me. Okay :)