From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
QEMU <qemu-devel@nongnu.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH] tools/virtiofsd: add support for --socket-group
Date: Mon, 16 Mar 2020 10:33:31 +0000 [thread overview]
Message-ID: <20200316103331.GC1528804@redhat.com> (raw)
In-Reply-To: <CAJ+F1CJWy2gEHHjzqyqnvHFf6EP4mEGABLt4aA7xptkXDwPGiw@mail.gmail.com>
On Sat, Mar 14, 2020 at 02:33:25PM +0100, Marc-André Lureau wrote:
> Hi
>
> On Thu, Mar 12, 2020 at 11:49 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Mar 12, 2020 at 10:41:42AM +0000, Alex Bennée wrote:
> > > If you like running QEMU as a normal user (very common for TCG runs)
> > > but you have to run virtiofsd as a root user you run into connection
> > > problems. Adding support for an optional --socket-group allows the
> > > users to keep using the command line.
> >
> > If we're going to support this, then I think we need to put it in
> > the vhost-user.rst specification so we standardize across backends.
> >
> >
>
> Perhaps. Otoh, I wonder if the backend spec should be more limited to
> arguments/introspection that are used by programs.
>
> In this case, I even consider --socket-path to be unnecessary, as a
> management layer can/should provide a preopened & setup fd directly.
>
> What do you think?
I think there's value in standardization even if it is an option targetted
at human admins, rather than machine usage. You are right though that
something like libvirt would never use --socket-group, or --socket-path.
Even admins would benefit if all programs followed the same naming for
these. We could document such options as "SHOULD" rather than "MUST"
IOW, we don't mandate --socket-group, but if you're going to provide a
way to control socket group, this option should be used.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2020-03-16 10:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 10:41 [PATCH] tools/virtiofsd: add support for --socket-group Alex Bennée
2020-03-12 10:49 ` Daniel P. Berrangé
2020-03-14 13:33 ` Marc-André Lureau
2020-03-16 10:33 ` Daniel P. Berrangé [this message]
2020-03-17 9:54 ` Stefan Hajnoczi
2020-03-17 18:47 ` Dr. David Alan Gilbert
2020-03-17 23:21 ` Alex Bennée
2020-03-17 23:54 ` Marc-André Lureau
2020-03-14 13:25 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200316103331.GC1528804@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=dgilbert@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.