From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: virtio-fs@redhat.com,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Virtio-fs] [Qemu-devel] [RFC 2/3] virtiofsd: add DBus server to handle log level changes
Date: Fri, 6 Sep 2019 12:12:23 +0100 [thread overview]
Message-ID: <20190906111223.GD2699@work-vm> (raw)
In-Reply-To: <20190906104953.GV5119@redhat.com>
* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Fri, Sep 06, 2019 at 11:23:28AM +0100, Stefan Hajnoczi wrote:
> > On Thu, Sep 05, 2019 at 06:27:32PM +0100, Dr. David Alan Gilbert wrote:
> > > * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > > > Introduce a DBus server thread that runs alongside the other virtiofsd
> > > > threads. It processes changes to the /org/qemu/virtiofsd object which
> > > > can be accessed at the org.qemu.virtiofsd location on the bus.
> > > >
> > > > This code does not use locking because we are the only writer to the
> > > > int current_log_level variable. More advanced management commands would
> > > > require locking to prevent race conditions with the other threads.
> > > >
> > > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > >
> > > OK, that is less complex than I'd feared.
> > > I guess there's something probably nice to do with name/integer mapping
> > > for warning levels that we could use from one of the libraries.
> >
> > I used a free-form string because it's what systemd's LogLevel property
> > also does. But I can investigate the cleanest approach for limiting it
> > to a set of string constants.
>
> There's no concept of "enums" at the DBus protocol level. Sending enums
> in string form is the normal practice - avoiding integer values means
> you are not vulnerable to enum values changing if someone inserts a new
> constant in the middlle of the enum. This same reason is why QAPI uses
> strings for enums instead of ints.
Oh, I wasn't talking aobut changing protocol; I just meant there was
probably a neater way of doing the string look up than the opencoded way
it was done.
Dave
> 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 :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: virtio-fs@redhat.com,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Eryu Guan" <eguan@linux.alibaba.com>,
qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC 2/3] virtiofsd: add DBus server to handle log level changes
Date: Fri, 6 Sep 2019 12:12:23 +0100 [thread overview]
Message-ID: <20190906111223.GD2699@work-vm> (raw)
In-Reply-To: <20190906104953.GV5119@redhat.com>
* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Fri, Sep 06, 2019 at 11:23:28AM +0100, Stefan Hajnoczi wrote:
> > On Thu, Sep 05, 2019 at 06:27:32PM +0100, Dr. David Alan Gilbert wrote:
> > > * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > > > Introduce a DBus server thread that runs alongside the other virtiofsd
> > > > threads. It processes changes to the /org/qemu/virtiofsd object which
> > > > can be accessed at the org.qemu.virtiofsd location on the bus.
> > > >
> > > > This code does not use locking because we are the only writer to the
> > > > int current_log_level variable. More advanced management commands would
> > > > require locking to prevent race conditions with the other threads.
> > > >
> > > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > >
> > > OK, that is less complex than I'd feared.
> > > I guess there's something probably nice to do with name/integer mapping
> > > for warning levels that we could use from one of the libraries.
> >
> > I used a free-form string because it's what systemd's LogLevel property
> > also does. But I can investigate the cleanest approach for limiting it
> > to a set of string constants.
>
> There's no concept of "enums" at the DBus protocol level. Sending enums
> in string form is the normal practice - avoiding integer values means
> you are not vulnerable to enum values changing if someone inserts a new
> constant in the middlle of the enum. This same reason is why QAPI uses
> strings for enums instead of ints.
Oh, I wasn't talking aobut changing protocol; I just meant there was
probably a neater way of doing the string look up than the opencoded way
it was done.
Dave
> 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 :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-09-06 11:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 15:21 [Virtio-fs] [RFC 0/3] virtiofsd: get/set log level via DBus Stefan Hajnoczi
2019-09-05 15:21 ` [Qemu-devel] " Stefan Hajnoczi
2019-09-05 15:21 ` [Virtio-fs] [RFC 1/3] virtiofsd: add org.qemu.Virtiofsd interface Stefan Hajnoczi
2019-09-05 15:21 ` [Qemu-devel] " Stefan Hajnoczi
2019-09-05 15:21 ` [Virtio-fs] [RFC 2/3] virtiofsd: add DBus server to handle log level changes Stefan Hajnoczi
2019-09-05 15:21 ` [Qemu-devel] " Stefan Hajnoczi
2019-09-05 17:27 ` [Virtio-fs] " Dr. David Alan Gilbert
2019-09-05 17:27 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-09-06 10:23 ` [Virtio-fs] " Stefan Hajnoczi
2019-09-06 10:23 ` [Qemu-devel] " Stefan Hajnoczi
2019-09-06 10:49 ` [Virtio-fs] " Daniel P. Berrangé
2019-09-06 10:49 ` Daniel P. Berrangé
2019-09-06 11:12 ` Dr. David Alan Gilbert [this message]
2019-09-06 11:12 ` Dr. David Alan Gilbert
2019-09-06 11:48 ` [Virtio-fs] " Daniel P. Berrangé
2019-09-06 11:48 ` Daniel P. Berrangé
2019-09-05 15:21 ` [Virtio-fs] [RFC 3/3] virtiofsd: add virtiofsctl command-line management tool Stefan Hajnoczi
2019-09-05 15:21 ` [Qemu-devel] " Stefan Hajnoczi
2019-09-05 17:12 ` [Virtio-fs] " Dr. David Alan Gilbert
2019-09-05 17:12 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-09-05 20:03 ` [Virtio-fs] " Marc-André Lureau
2019-09-05 20:03 ` [Qemu-devel] " Marc-André Lureau
2019-09-06 10:33 ` [Virtio-fs] " Stefan Hajnoczi
2019-09-06 10:33 ` [Qemu-devel] " Stefan Hajnoczi
2019-09-05 17:40 ` [Virtio-fs] [RFC 0/3] virtiofsd: get/set log level via DBus Dr. David Alan Gilbert
2019-09-05 17:40 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-09-06 10:29 ` [Virtio-fs] " Stefan Hajnoczi
2019-09-06 10:29 ` [Qemu-devel] " Stefan Hajnoczi
2019-09-06 10:35 ` [Virtio-fs] " Dr. David Alan Gilbert
2019-09-06 10:35 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-09-06 11:03 ` [Virtio-fs] " Daniel P. Berrangé
2019-09-06 11:03 ` Daniel P. Berrangé
2019-09-06 10:47 ` [Virtio-fs] " Daniel P. Berrangé
2019-09-06 10:47 ` Daniel P. Berrangé
2019-09-09 12:37 ` [Virtio-fs] " Stefan Hajnoczi
2019-09-09 12:37 ` [Qemu-devel] " 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=20190906111223.GD2699@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-fs@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.