Hi,
On 03/20/2013 07:59 PM, Anthony Liguori wrote:
Alon Levy <al...@redhat.com> writes:
Alon Levy <al...@redhat.com> writes:
Signed-off-by: Alon Levy <al...@redhat.com>
---
include/char/char.h | 12 ++++++++++++
qemu-char.c | 7 +++++++
2 files changed, 19 insertions(+)
diff --git a/include/char/char.h b/include/char/char.h
index 0326b2a..0fdcaf9 100644
--- a/include/char/char.h
+++ b/include/char/char.h
@@ -70,6 +70,7 @@ struct CharDriverState {
void (*chr_set_echo)(struct CharDriverState *chr, bool echo);
void (*chr_guest_open)(struct CharDriverState *chr);
void (*chr_guest_close)(struct CharDriverState *chr);
+ void (*chr_post_load)(struct CharDriverState *chr, int
connected);
The character device layer should *not* be messing around with
notifying
migration state.
I thought we previously discussed this? Just implement a migration
hook
in the spice code.
The thing Gerd objected to when I sent a patch doing just that was the
way I used the vmstate, one possible way to not have to use vmstate at
all is adding api for querying the current front end connected status,
like qemu_fe_is_connected. Is that acceptable?
To determine if the backend is connected?
No to query if the front-end is connected to the guest, with virtio-ports
just because they are there does not mean the guest is listening,
so qemu_fe_is_connected is the right name, or maybe
qemu_fe_is_guest_connected
If so, it's fine, but I'd
suggest being more explicit and calling it qemu_fe_is_be_connected().
Definitely not qemu_fe_is_be_connected that would mean asking if a chardev
backend is connected, which is not what we're interested in (we're calling
this from a backend, so we know we're connected ourselves).
Regards,
Hans
