Il 16/12/2013 08:32, Edgar E. Iglesias ha scritto: > On Fri, Dec 13, 2013 at 12:14:31PM +0100, Antonios Motakis wrote: >> This option complements -mem-path. It implies -mem-prealloc. If specified, >> the guest RAM is allocated as a shared memory object. If both -mem-path >> and -mem-share are provided, the memory is allocated from the HugeTLBFS >> supplied path, and then mmapped with MAP_SHARED. > > Hi, > > Interesting, I've got a similar use-case here where I've added a -mem-shared > option. I've got a few comments/questions. > > Why do you imply -mem-prealloc? cant the user keep controlling that through > -mem-prealloc? > > I'd prefer if -mem-share did not use shm_open but took a directory path as arg > and created the backing files there. I'd also prefer if the files had > deterministic names and where not unlinked after creation. I.e, let the user > delete them when no longer needed. > > The reason for this is that it makes it easier to use apps that are not > aware of shm or QEMU specifics to manipulate the memory backing. I understand > that there might be issues (e.g filling up the disk, slow access over NFS etc) > but these are at the choice of the user. > > Any thoughts around this?
I agree entirely with you. Paolo
