On 14/09/09 13:37, Richard W.M. Jones wrote:
On Mon, Sep 14, 2009 at 01:18:40PM +0100, Matthew Booth wrote:
> On 14/09/09 12:51, Richard W.M. Jones wrote:
>> On Mon, Sep 14, 2009 at 12:44:15PM +0100, Matthew Booth wrote:
>>> On 14/09/09 12:10, Richard W.M. Jones wrote:
>>>> This is the only patch I currently have outstanding. No changes from
>>>> the previous posting, except I rebased it against the head of git.
>>>
>>> I'm still reviewing this (and probably will be for a while). I have a
>>> high-level observation at this stage, though. Several error paths in
>>> this code (and the previous code, too) would be a whole lot simpler if
>>> LAUNCH and CANCEL were turned into real protocol messages, and receive
>>> file was terminated with ACK. This would also simplify review.
>>
>> We can't change the protocol because it's baked into other appliances
>> that we've shipped and people could use the wrong appliance and
>> library version combination. (At the moment this does work).
>
> Well, the appliance is an integral part of libguestfs, which is also why
> they're shipped together. The protocol really is an internal
> implementation detail, not part of the API. I don't see any problem
> changing the protocol.
In theory, but our advice for packagers (on non-Debian, non-Red Hat
distributions) has been to pull the Fedora binary appliance out of the
packages:
http://libguestfs.org/FAQ.html#distros
Then give it a bigger version bump and stick a release note in ;)
Also you can set LIBGUESTFS_PATH and point it to any appliance you
want, and most likely it will work.
Anyhow, changing the protocol itself (which is very well tested) is
outside the scope of this patch.
This patch invalidates all that testing, because it effectively changes
the entire implementation of the protocol. I suggest that this is a
perfect opportunity to also fix the protocol, if not in this patch, then
in one to follow closely afterwards.
The cancellation of file sends is certainly broken at the protocol
level. Everywhere we ignore cancellation messages in the implementation
is simply an indication of this. It's broken because there's no ACK at
the end of a successful send, which means that the host cannot know if
the file was successfully written to the guest or not unless the write
fails before the end of the transmission.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490