qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/9] qemu_qsb.diff


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH 4/9] qemu_qsb.diff
Date: Wed, 13 Mar 2013 17:28:56 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 03/13/2013 05:11 PM, mdroth wrote:
On Wed, Mar 13, 2013 at 01:56:23PM -0500, Joel Schopp wrote:
This patch adds support functions for operating on in memory sized file buffers.
There's been some past refactorings to remove non-migration users of
QEMUFile, and AFAIK that's still the case today. QEMUFile satisfies
funky requirements like rate-limiting, buffering, etc that were specific
to migration.

IIUC all we want here is an abstraction on top of write()/memcpy(),
and access to qemu_{put|get}_be* utility functions.

Have you considered rolling those abstractions in the visitor
implementations as opposed to extending QEMUFile, and using
be*_to_cpus/cpus_to_be* helpers directly instead (like block/qcow2.c
does, for example)?

The advantage of using the QEMUFile abstractions is that now you can build a visitor on top of it and read from buffers, sockets, BDRV's (later on), plain files, and whatever else you can hide underneath that interface. Back in 2011 when I initially wrote this code there at least was talk about using ASN.1 for migration, but this is nearly 2 years ago and it may never be done that way, so this was one driving force behind using QEMUFile inside the visitor. Besides that we later want to use the visitors for writing into virtual NVRAM, which we would build on top of a QEMUFile wrapping BDRVs. So there are some immediate advantages of using the common QEMUFile interface for reading and writing of data from different types of sources.

   Regards,
      Stefan




reply via email to

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