qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 33/42] ivshmem: Implement shm=... with a memo


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 33/42] ivshmem: Implement shm=... with a memory backend
Date: Thu, 10 Mar 2016 07:48:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Marc-André Lureau <address@hidden> writes:

> Hi
>
> On Wed, Mar 9, 2016 at 9:59 PM, Markus Armbruster <address@hidden> 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 :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]