All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: libvir-list@redhat.com, "Ján Tomko" <jtomko@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QMP; unsigned 64-bit ints; JSON standards compliance
Date: Mon, 13 May 2019 15:10:07 +0100	[thread overview]
Message-ID: <20190513141007.GK15029@redhat.com> (raw)
In-Reply-To: <87ef525uls.fsf@dusky.pond.sub.org>

On Mon, May 13, 2019 at 03:53:19PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
> [...]
> >> Double-checking: do you propose to encode *all* numbers as strings, or
> >> just certain "problematic" numbers?
> >> 
> >> If the latter, I guess your idea of "problematic" is "not representable
> >> exactly as double precision floating-point".
> >
> > We have a few options
> >
> >  1. Use string format for values > 2^53-1, int format below that
> >  2. Use string format for all fields which are 64-bit ints whether
> >     signed or unsigned
> >  3. Use string format for all fields which are integers, even 32-bit
> >     ones
> >
> > I would probably suggest option 2. It would make the QEMU impl quite
> > easy IIUC, we we'd just change the QAPI visitor's impl for the int64
> > and uint64 fields to use string format (when the right capability is
> > negotiated by QMP).
> >
> > I include 3 only for completeness - I don't think there's a hugely
> > compelling reason to mess with 32-bit ints.
> 
> Agree.
> 
> > Option 1 is the bare minimum needed to ensure precision, but to me
> > it feels a bit dirty to say a given field will have different encoding
> > depending on the value. If apps need to deal with string encoding, they
> > might as well just use it for all values in a given field.
> 
> I guess that depends on what this interoperability capability does for
> QMP *input*.
> 
> For *output*, QEMU has to encode a number either as JSON number or as
> JSON string
> 
> For *input*, QEMU could accept either.  Or it could accept only the
> encoding it produces on output.
> 
> Got a preference?

IMHO if a mgmt app enables the (hypothetically named) "int64-as-string"
capability, then we should be strict and require string format on both
input & output. If QEMU accepted either, it would silently hide bugs
where the app has mistakenly not used string formatting.


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 :|


  reply	other threads:[~2019-05-13 14:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30 13:19 [Qemu-devel] QMP; unsigned 64-bit ints; JSON standards compliance Daniel P. Berrangé
2019-04-30 13:19 ` Daniel P. Berrangé
2019-04-30 14:45 ` Dr. David Alan Gilbert
2019-04-30 14:45   ` Dr. David Alan Gilbert
2019-04-30 15:05   ` Daniel P. Berrangé
2019-04-30 15:05     ` Daniel P. Berrangé
2019-05-07  8:47     ` Markus Armbruster
2019-05-07  9:39       ` Daniel P. Berrangé
2019-05-07 16:32         ` Eric Blake
2019-05-08 12:37           ` Markus Armbruster
2019-05-08 12:44             ` Dr. David Alan Gilbert
2019-05-08 12:44         ` Markus Armbruster
2019-05-13 12:08           ` Daniel P. Berrangé
2019-05-13 12:29             ` Dr. David Alan Gilbert
2019-05-13 12:35               ` Daniel P. Berrangé
2019-05-13 14:10                 ` Markus Armbruster
2019-05-13 13:53             ` Markus Armbruster
2019-05-13 14:10               ` Daniel P. Berrangé [this message]
2019-05-13 15:15               ` [Qemu-devel] [libvirt] " Eric Blake
2019-05-14  6:02                 ` Markus Armbruster
2019-05-14  9:26                   ` Daniel P. Berrangé
2019-05-14  9:37                     ` Dr. David Alan Gilbert
2019-05-14  9:43                       ` Daniel P. Berrangé
2019-05-14  9:47                         ` Peter Krempa
2019-06-04  6:38 ` [Qemu-devel] " Markus Armbruster
2019-06-05 13:06   ` Daniel P. Berrangé

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=20190513141007.GK15029@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=jtomko@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.