* Chuan Zheng ([email protected]) wrote:
> Signed-off-by: Zhimin Feng <[email protected]>
> Signed-off-by: Chuan Zheng <[email protected]>
> ---
> migration/qemu-file.c | 5 +++++
> migration/qemu-file.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/migration/qemu-file.c b/migration/qemu-file.c
> index be21518..37f6201 100644
> --- a/migration/qemu-file.c
> +++ b/migration/qemu-file.c
> @@ -260,6 +260,11 @@ void ram_control_before_iterate(QEMUFile *f, uint64_t
> flags)
> }
> }
>
> +void *getQIOChannel(QEMUFile *f)
> +{
> + return f->opaque;
> +}
> +
Unfortunately that's not right, since the opaque isn't always a
QUIChannel, so getOpaque would be a suitable name here.
It's a shame this is needed; I'm surprised you ever have a QEMUFIle* in
the rdma code in somewhere you don't have the QIOChannel; could you
avoid this by adding a QIOChannel pointer into the RDAMContext to point
back to the channel which it's for?
Dave
> void ram_control_after_iterate(QEMUFile *f, uint64_t flags)
> {
> int ret = 0;
> diff --git a/migration/qemu-file.h b/migration/qemu-file.h
> index a9b6d6c..4cef043 100644
> --- a/migration/qemu-file.h
> +++ b/migration/qemu-file.h
> @@ -165,6 +165,7 @@ void qemu_file_set_blocking(QEMUFile *f, bool block);
> void ram_control_before_iterate(QEMUFile *f, uint64_t flags);
> void ram_control_after_iterate(QEMUFile *f, uint64_t flags);
> void ram_control_load_hook(QEMUFile *f, uint64_t flags, void *data);
> +void *getQIOChannel(QEMUFile *f);
>
> /* Whenever this is found in the data stream, the flags
> * will be passed to ram_control_load_hook in the incoming-migration
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
