On Tue, Sep 27, 2016 at 11:01:10AM -0000, Rafael David Tinoco wrote:
> > On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> 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 ?
On Tue, Sep 27, 2016 at 11:01:10AM -0000, Rafael David Tinoco wrote: 546c395a566b04e 63ca84e302 added a fallback
> > On Sep 27, 2016, at 05:36, Daniel P. Berrange <email address hidden> wrote:
> >
> > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote:
> >> Commit: 35f9b6ef3acc9d0
> >> 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, berrange. com -o- http:// www.flickr. com/photos/ dberrange/ :| libvirt. org -o- http:// virt-manager. org :| autobuild. org -o- http:// search. cpan.org/ ~danberr/ :| entangle- photo.org -o- http:// live.gnome. org/gtk- vnc :|
Daniel
--
|: http://
|: http://
|: http://
|: http://