qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 07/18] Introduce fault tolerant VM transaction Q


From: Yoshiaki Tamura
Subject: [Qemu-devel] Re: [PATCH 07/18] Introduce fault tolerant VM transaction QEMUFile and ft_mode.
Date: Thu, 24 Feb 2011 18:44:59 +0900

2011/2/24 Juan Quintela <address@hidden>:
>
> [ trimming cc to kvm & qemu lists]
>
> Yoshiaki Tamura <address@hidden> wrote:
>> Juan Quintela wrote:
>>> Yoshiaki Tamura<address@hidden>  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 address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]