[Top][All Lists]

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

Re: [Qemu-devel] Re: [RFC][PATCH v5 08/21] virtagent: add agent_viewfile

From: Michael Roth
Subject: Re: [Qemu-devel] Re: [RFC][PATCH v5 08/21] virtagent: add agent_viewfile qmp/hmp command
Date: Tue, 07 Dec 2010 08:09:15 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20101027 Thunderbird/3.1.6

On 12/06/2010 05:20 PM, Michael Roth wrote:
On 12/06/2010 04:08 PM, Adam Litke wrote:
On Fri, 2010-12-03 at 12:03 -0600, Michael Roth wrote:
Utilize the getfile RPC to provide a means to view text files in the
guest. Getfile can handle binary files as well but we don't advertise
that here due to the special handling requiring to store it and provide
it back to the user (base64 encoding it for instance). Hence the
otherwise confusing "viewfile" as opposed to "getfile".

What happens to the monitor if you use this to view a binary file?

At the very least we probably get a lot of truncated files from the
binary->string conversion via monitor_printf(). Im not sure how the
qobject/json layer would deal with things.

Retrieving binary files progmatically using the QMP interface is a valid
use case right?

For getfile (the RPC), but not for viewfile (HMP/QMP). It's doable, but
we'd *have to* pass this data to the user as base64-encoded data at the
QMP level. At the HMP level I think we're good either way, since we
could just base64 decode in the print function.

So in the case of QMP we'd be pushing complexity to the user in exchange
for not having a seperate plain-text-only interface.

Either way seems reasonable, but I'd been planning on adding a seperate
`agent_copyfile <remote_path> <local_path>` command for dealing with
binary data, and making viewfile quick and easy for plain text (both for
HMP and QMP).

Although, agent_copyfile doesn't seem like the right approach looking at things like future libvirt integration. So we will most likely end up with a QMP command that passes base64-encoded binary data to the end-user for binary data, which we can provide a pretty-printing HMP function to decode. We'd need to take care to differentiate the HMP command from the QMP one however, else we'd have users tempted to do something like:

echo "agent_getfile /remotepath/rand.bin" | socat stdin unix-connect:monitor.sock > /localpath/rand.bin

to avoid having to decode the data. Would documenting the HMP counterpart as being reliable only for plain-text be sufficient? Or Should be have QMP:agent_getfile() and HMP:agent_viewfile()?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]