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

Re: [Libguestfs] [PATCH REBASED] Remove main loop



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


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