[ trimming cc to kvm & qemu lists] Yoshiaki Tamura <tamura.yoshi...@lab.ntt.co.jp> wrote: > Juan Quintela wrote: >> Yoshiaki Tamura<tamura.yoshi...@lab.ntt.co.jp> wrote: >>> This code implements VM transaction protocol. Like buffered_file, it >>> sits between savevm and migration layer. With this architecture, VM >>> transaction protocol is implemented mostly independent from other >>> existing code. >> >> Could you explain what is the difference with buffered_file.c? >> I am fixing problems on buffered_file, and having something that copies >> lot of code from there makes me nervous. > > The objective is different: > > buffered_file buffers data for transmission control. > ft_trans_file adds headers to the stream, and controls the transaction > between sender and receiver. > > Although ft_trans_file sometimes buffers date, but it's not the main > objective. > If you're fixing the problems on buffered_file, I'll keep eyes on them. > >>> +typedef ssize_t (FtTransPutBufferFunc)(void *opaque, const void *data, >>> size_t size); >> >> Can we get some sharing here? >> typedef ssize_t (BufferedPutFunc)(void *opaque, const void *data, size_t >> size); >> >> There are not so much types for a write function that the 1st element is >> one opaque :p > > You're right, but I want to keep ft_trans_file independent of > buffered_file at this point. Once Kemari gets merged, I'm happy to > work with you to fix the problems on buffered_file and ft_trans_file, > and refactoring them.
My goal is getting its own thread for migration on 0.15, that basically means that we can do rm buffered_file.c. I guess that something similar could happen for kemari. But for now, this is just the start + handwaving, once I start doing the work I will told you. Later, Juan.
