Peter Xu <pet...@redhat.com> wrote:
> On Mon, Jun 05, 2017 at 01:34:45PM +0100, Dr. David Alan Gilbert wrote:
>> * Juan Quintela (quint...@redhat.com) wrote:
>> > RAM Statistics need to survive migration to make info migrate work, so we
>> > need to store them outside of RAMState. As we already have an struct
>> > with those fields, just used them. (MigrationStats and XBZRLECacheStats).
>> >
>> > Signed-off-by: Juan Quintela <quint...@redhat.com>
>>
>> Hmm OK; this feels very much like it's the opposite of 180f61f from
>> March; these variables keep moving around over the last couple of months
>> - are they going to stay still now?
>
> O:-)
>
> Meanwhile, I don't know whether it'll be necessary to remove all the
> functions like ram_bytes_transferred(), e.g., it would be just:
>
> uint64_t ram_bytes_transferred(void)
> {
> - return ram_state.bytes_transferred;
> + return ram_counters.transferred;
> }
>
> But I'm okay with either.
That value was only used for filling the statistics. And we are filling
a struct from another struct of the exact same type. Going through an
exported function looks stranger.
And as said in $commit, the idea was that creating a new counter was
easy, right now you have to:
- add it to MigrationParam (still have to do this)
- add it to MigrationParams (still have to do this)
- create the field in MigrationStats or RAMState
- create a function that exports it
- add that function in ram.h to export it
- add it on qmp_query (still have to do this)
So, we are moving from 6 steps to 3 steps. I think we are much better
now, no? O:-)
Later, Juan.
