Re: [PATCH 07/18] Introduce fault tolerant VM transaction QEMUFile and ft_mode.

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

 



2011/2/24 Juan Quintela <quintela@xxxxxxxxxx>:
>
> [ trimming cc to kvm & qemu lists]
>
> Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> wrote:
>> Juan Quintela wrote:
>>> Yoshiaki Tamura<tamura.yoshiaki@xxxxxxxxxxxxx>  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.

That means both gets initiated by it's own thread, not like
current poll based.  I'm still skeptical whether Anthony agrees,
but I'll keep it in my mind.

> But for now, this is just the start + handwaving, once I start doing the
> work I will told you.

Yes, please.

Yoshi

>
> Later, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux