Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Sun, Nov 18, 2018 at 06:25:53PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Nov 16, 2018 at 10:39:07AM +0000, Anthony PERARD wrote:
> > The 'guest-sync-delimited' command doesn't seems to be available on the
> > monitor socket. I should have checked that ... but that would just mean
> > that libxl would need to tolerate the first read to be an incompleted
> > json-object. Then we can use the 'id' that every response have to figure
> > out if it was a reply sent to a previous libxl run. We can maybe encode
> > the pid into the id.
> 
> It may be tricky to figure out where is the end of such incomplete json
> object... Suppose you read:
> 
> { "x": { "y": 1 } } }
> 
> If you read this from the beginning looking for json, you'll get valid
> json object unless you encounter the last "}" (which you may receive in
> separate read() call, if you're unlucky). I'm afraid the logic for
> skipping initial (possibly incomplete) object(s) may be quite complex.

It's not that complex, all messages sent by QEMU are terminated by CRLF,
that part of the protocol. So I think that libxl already return an error
if it get something like: '{ "z": 2 } }\r\n', because of that extra }
that should not be there.

> Maybe better propose upstream to include 'guest-sync-delimited' also on
> monitor socket too? In that case, the command naming will be awkward,
> but still, similar command would be useful in that context.

It might be usefull to have.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel