On Montag, 7. Februar 2022 15:39:30 CET Greg Kurz wrote: > On Mon, 07 Feb 2022 15:15:46 +0100 > > Christian Schoenebeck <qemu_...@crudebyte.com> wrote: > > On Montag, 7. Februar 2022 02:05:32 CET Will Cohen wrote: > > > On Sun, Feb 6, 2022 at 4:22 PM Philippe Mathieu-Daudé <f4...@amsat.org> > > > > > > wrote: > > > > On 6/2/22 21:07, Will Cohen wrote: > > > > > From: Keno Fischer <k...@juliacomputing.com> > > > > > > > > > > Signed-off-by: Keno Fischer <k...@juliacomputing.com> > > > > > [Michael Roitzsch: - Rebase for NixOS] > > > > > Signed-off-by: Michael Roitzsch <reactorcont...@icloud.com> > > > > > [Will Cohen: - Rebase to master] > > > > > Signed-off-by: Will Cohen <wwco...@gmail.com> > > > > > Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> > > > > > [Will Cohen: - Add check for pthread_fchdir_np to virtfs] > > > > > Signed-off-by: Will Cohen <wwco...@gmail.com> > > > > > --- > > > > > > > > > > fsdev/meson.build | 1 + > > > > > meson.build | 14 ++++++++++---- > > > > > 2 files changed, 11 insertions(+), 4 deletions(-) > > > > > > > > > > -have_virtfs_proxy_helper = have_virtfs and have_tools > > > > > +have_virtfs_proxy_helper = targetos == 'linux' and have_virtfs and > > > > > > > > have_tools > > > > > > > > Why do you restrict the proxy-helper to Linux? > > > > > > Only because porting the proxy-helper to macOS is outside the scope of > > > this > > > particular patch. While some initial concepts around it have been > > > considered by some of the contributors to this patch, those > > > implementations > > > weren't tested enough and the security implications weren't considered > > > in > > > full. We assume that this could be an additional implementation later > > > on, > > > if the functionality is considered important down the road. > > > > In general that's fine with me. I would have probably made that > > "targetos != 'darwin'" instead of "targetos == 'linux'", but I leave that > > up to you. > > > > On the long term we will probably deprecate the 9p 'proxy' fs driver > > anyway. While it had some good ideas, being realistic though: nobody has > > worked on the 9p proxy driver/backend for many years and it is not in > > good shape. > It definitely isn't indeed. Also it is super slow by design > since the round trip of a 9p request involves QEMU on both entry > and exit: > > [guest] --> [QEMU]--> [virtfs-proxy-helper]-->[QEMU]-->[guest] > > A more modern and efficient approach would be to have a vhost-user-9p > implementation : requests would be directly handled by the external > process, without QEMU hops. But this a fair amount of work.
That's already a bit offtopic, but how would you imagine that to work? You mean a system dependent solution that e.g. plugs in into KVM or something? > > I can imagine that due to the ground being laid by these series, that we > > will also open 9p for BSD, but that should be done a bit later and hence > > does not belong into these series. > > > > But once again: it would not have hurt to make your intentions clear > > either in the commit log or by in-source comment. :) > > > > Best regards, > > Christian Schoenebeck
