All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000
Date: Mon, 23 May 2011 10:59:29 -0500	[thread overview]
Message-ID: <4DDA8461.2040704@codemonkey.ws> (raw)
In-Reply-To: <20110523152944.GK27503@amd.home.annexia.org>

On 05/23/2011 10:29 AM, Richard W.M. Jones wrote:
> On Mon, May 23, 2011 at 10:24:07AM -0500, Anthony Liguori wrote:
>> On 05/23/2011 10:19 AM, Richard W.M. Jones wrote:
>> What I suggested would let us work with any JSON client, but if
>> clients loose precision after 53-bits, those clients would not work
>> well with QEMU.
>
> I totally agree that the JSON "standard" is completely underspecified
> and not very useful (lacking a schema, strong typing, well-specified
> limits).  Nevertheless, for better or worse it's what we're using.
>
> There is one very important JSON client we are using called libvirt.

No, libvirt is a virtualization library.  It happens to have a home 
grown JSON client but down the road, if there's a nice, common JSON 
library and it decides to switch to it, we don't want to have a bunch of 
compatibility issues that prevents that from happening.

The point of using a standard RPC is to support multiple clients. 
Otherwise, we should just stop calling it JSON and make it behave the 
way we want it to.

>> The alternative approach is to be conservative and only use 32-bit
>> integers and represent everything in two numbers.
>
> Or use strings ...

JSON types are variant.  We could send integers great than 53-bits back 
as strings..  This would break libvirt badly though.

>
> Rich.
>

  reply	other threads:[~2011-05-23 15:59 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 18:03 [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 Richard W.M. Jones
2011-05-20 18:11 ` Anthony Liguori
2011-05-20 18:36   ` Richard W.M. Jones
2011-05-20 18:37     ` Richard W.M. Jones
2011-05-20 18:47   ` Richard W.M. Jones
2011-05-20 21:19   ` Richard W.M. Jones
2011-05-23 13:04   ` Daniel P. Berrange
2011-05-23 13:33     ` Anthony Liguori
2011-05-23 13:39       ` Richard W.M. Jones
2011-05-23 13:40       ` Daniel P. Berrange
2011-05-23 13:45         ` Anthony Liguori
2011-05-23 14:14           ` Daniel P. Berrange
2011-05-23 15:03             ` Anthony Liguori
2011-05-23 15:41               ` Daniel P. Berrange
2011-05-23 14:20           ` Markus Armbruster
2011-05-23 13:50         ` Anthony Liguori
2011-05-23 14:02           ` Luiz Capitulino
2011-05-23 14:06             ` Anthony Liguori
2011-05-23 14:24           ` Daniel P. Berrange
2011-05-23 14:29           ` Markus Armbruster
2011-05-23 14:32             ` Daniel P. Berrange
2011-05-23 15:07             ` Anthony Liguori
2011-05-23 15:19               ` Richard W.M. Jones
2011-05-23 15:24                 ` Anthony Liguori
2011-05-23 15:29                   ` Richard W.M. Jones
2011-05-23 15:59                     ` Anthony Liguori [this message]
2011-05-23 16:06                       ` Daniel P. Berrange
2011-05-23 15:38                   ` Daniel P. Berrange
2011-05-23 16:18                   ` Markus Armbruster
2011-05-23 16:37                     ` Anthony Liguori
2011-05-24  6:26                       ` Markus Armbruster
2011-05-23 23:02                 ` [Qemu-devel] Use a hex string (was: [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000) Jamie Lokier
2011-05-24  2:50                   ` [Qemu-devel] Use a hex string Anthony Liguori
2011-05-24  5:30                     ` Jamie Lokier
2011-05-23 13:38     ` [Qemu-devel] [PATCH] qemu: json: Fix parsing of integers >= 0x8000000000000000 Anthony Liguori

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=4DDA8461.2040704@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@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.