[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.