On 12/05/15 09:12, Yang Hongyang wrote: > >>>> That sounds like COLO wants a should_checkpoint() callback which >>>> separates the decision to make a checkpoint from the logic of >>>> implementing a checkpoint. >>> >>> We use checkpoint callback to do should_checkpoint() thing currently. >>> libxc will check the return value of checkpoint callback. >> >> But that causes a chicken & egg problem. >> >> I am planning to use a CHECKPOINT record to synchronise the transfer of >> ownership of the FD between libxc and libxl. Therefore, a CHECKPOINT >> record must be in the stream ahead of the checkpoint() callback, as >> libxl will then write/read some records in itself. > > The record name CHECKPOINT seems do not match the thing what you are > planning to do, In this case I think END-OF-CHECKPOINT which represent > the > END of libxc side checkpoint is better, when libxc side checkpoint end, > libxc should transfer the ownership of FD to libxl and let libxl to > handle the following stream. libxl side can also use END-OF-CHECKPOINT > as a sign to hand the ownership of the FD to libxc.
END_OF_CHECKPOINT implies the presence of START_OF_CHECKPOINT. The current spec for CHECKPOINT is more of a sentinal value between checkpoints of data. > >> >> As a result, the checkpoint() callback itself can't be used to gate >> whether a CHECKPOINT record is written by libxc. > > I was wondering how you will do the FD transfer job? The FD needs to be readable/writable in both the libxl and libxl-save-helper processes. The CHECKPOINT record simply signals a transfer of ownership. >>>> I have a 4th alternative in mind, but would like your feedback from my >>>> comments in this email first. >>> >>> So what's the 4th alternative? >> >> I have some corrections to my patch series based on David's feedback, >> and your comments. After that, it should hopefully be far easier to >> describe. > > OK, I've addressed all comments on my series and wait for your series > to continue :-) Sent. Sorry for the delay (I also have some XenServer issues I am working on atm). ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
