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

Reply via email to