* Chuan Zheng (zhengch...@huawei.com) wrote: > Signed-off-by: Zhimin Feng <fengzhim...@huawei.com> > Signed-off-by: Chuan Zheng <zhengch...@huawei.com> > --- > 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 / dgilb...@redhat.com / Manchester, UK