* Daniel P. Berrangé ([email protected]) 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 ([email protected]) 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 <[email protected]>
> > > 
> > > 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 / [email protected] / Manchester, UK

_______________________________________________
Virtio-fs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virtio-fs

Reply via email to