On Tue, Sep 27, 2016 at 11:01:10AM -0000, Rafael David Tinoco wrote: > > On Sep 27, 2016, at 05:36, Daniel P. Berrange <berra...@redhat.com> wrote: > > > > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: > >> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback > >> mechanism for systems not supporting memfd_create syscall (started > >> being supported since 3.17). > > > > This is really dubious code in general and IMHO should just > > be reverted. > > There are numerous people relying on older kernels in openstack > deployments - sometimes with specific drivers (ovswitch, dpdk, > infiniband) holding kernel upgrades - but still in need of upgrading > userland (e.g. newer releases). Having a fallback mechanism seems > appropriate for those cases.
I'm not against some kind of fallback - just about the way it silently creates files in /tmp. > > Note that the filename, per se, is not as important as other files, > since qemu won't provide it for being accessed by external programs, and, > deletes the file, while keeping the descriptor, right after its creation > (due to its nature, that is probably why it was created in /tmp). If it doesn't shared with other processes, and is deleted immediately, why does the file need to be on disk at all ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
