On 12/07/10 17:00, Adam Litke wrote:
Hi Jes, you raise some good points and pitfalls with the current getfile
approach. I've been thinking about an alternative and am wondering what
you (and others) think...
First off, I think we should switch to a copyfile() API that allows us
to avoid presenting the file contents to the user. Neither the human
monitor nor the control monitor are designed to be file pagers. Let the
user decide how to consume the data once it has been transferred. Now
we don't need to care if the file is binary or text.
The virtagent RPC protocol is bi-directional and supports asynchronous
events. We can use these to implement a better copyfile RPC that can
transfer larger files without wasting memory. The host issues a
copyfile(<guest-path>,<host-path>) RPC. The immediate result of this
call will indicate whether the guest is able to initiate the transfer.
The guest will generate a series of events (<offset>,<size>,<payload>)
until the entire contents has been transferred. The host and guest
could negotiate the chunk size if necessary. Once the transfer is
complete, the guest sends a final event to indicate this (<file-size>,
0).
This interface could be integrated into the monitor with a pair of
commands (va_copyfile and info va_copyfile), the former used to initiate
transfers and the latter to check on the status.
Thoughts on this?
Hi Adam,
This sounds a lot safer than the current approach. Intuitively I would
think it should be the host controlling the copy, but otherwise it
sounds good. Or is there a reason why the guest should control it?