Am 05.10.2015 um 15:01 hat Peter Krempa geschrieben:
> On Mon, Oct 05, 2015 at 14:51:00 +0200, Kevin Wolf wrote:
> > Am 05.10.2015 um 13:01 hat Peter Krempa geschrieben:
> > > On Mon, Oct 05, 2015 at 15:30:42 +0530, Prasanna Kumar Kalever wrote:
>
> ...
>
> > > > resultant string:
> > > > -drive file=json:{
> > >
> > > > "file": {
> > > > "driver": "gluster",,
> > > > "volname": "testvol",,
> > > > "image-path": "/a.qcow2",,
> > > > "volfile-servers": [
> > > > {
> > > > "server": "1.2.3.4",,
> > > > "port": 24009,,
> > > > "transport": "tcp"
> > > > },,
> > > > {
> > > > "server": "3.4.5.6",,
> > > > "port": 24008,,
> > > > "transport": "tcp"
> > > > },,
> > > > {
> > > > "server": "5.6.7.8",,
> > > > "port": 24007,,
> > >
> > > The double commas look like a result of our command line escaping
> > > function. Are they actually required with 'json:' sources? If no, we
> > > will need probably a way to avoid them.
> >
> > This looks like it's used on the command line (i.e. the file=...
> > parameter of -drive). In this case, the escaping is necessary so the
> > string isn't split in the middle of the JSON object.
>
> Okay, so then our shell escaper is doing the right thing here.
>
> >
> > If you used the same thing in a blockdev-add QMP command, you wouldn't
> > need escaping, obviously, and double commas would be a syntax error.
> >
> > It's possible to avoid JSON syntax on the command line, but as you
> > mentioned yourself below, it's necessary in other contexts (backing file
> > strings), so it probably makes sense to use it here as well.
> >
> > For the record, the version without JSON would look like this (without
> > the whitespace; only formatting it this way for readability):
> >
> > -drive file.driver=gluster,
> > file.volname=testvol,
> > file.image-path=/a.qcow2,
> > file.volfile-servers.0.server=1.2.3.4,
> > file.volfile-servers.0.port=24009,
>
> It looks like that the syntax above can be very well generated from the
> same data structures we use to generate the JSON code. That was also my
> original thought how I'd approach this. On the commandline I'd use the
> syntax above via a separate generator and on monitor we can go with
> json. This will allow us to avoid the uglyness of json on the commannd
> line and the output might perhaps be even shorter.
No, most certainly it won't be shorter.
The biggest drawback of the dot syntax is that it repeats long prefixes
all the time, so contrary to what you might intuitively think, for
humans reading a command line might actually become harder (especially
if options aren't ordered) than with JSON syntax, which at least keeps
all fields of a single object in the same place.
As far as qemu is concerned, you're free to choose whatever you prefer,
though. The first thing that is done with json: filenames is that they
are extracted as if they were separatly specified options, so there's
no semantic difference.
> At any rate we definitely need a parser and a formatter for the json
> options.
You do. :-)
Kevin
Attachment:
pgpHxtDn5adWQ.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list