qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed


From: Luiz Capitulino
Subject: [Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed port/device add
Date: Fri, 26 Mar 2010 10:14:02 -0300

On Fri, 26 Mar 2010 07:46:28 +0530
Amit Shah <address@hidden> wrote:

> On (Thu) Mar 25 2010 [15:55:41], Luiz Capitulino wrote:
> > On Wed, 24 Mar 2010 20:19:28 +0530
> > Amit Shah <address@hidden> wrote:
> > 
> > > When adding a port or a device to the guest fails, management software
> > > might be interested in knowing and then cleaning up the host-side of the
> > > port. Introduce QMP events to signal such errors.
> > > 
> > > Signed-off-by: Amit Shah <address@hidden>
> > > CC: Luiz Capitulino <address@hidden>
> > > ---
> > >  QMP/qmp-events.txt     |   48 
> > > ++++++++++++++++++++++++++++++++++++++++++++++++
> > >  hw/virtio-serial-bus.c |   15 +++++++++++++++
> > >  monitor.c              |    3 +++
> > >  monitor.h              |    1 +
> > >  4 files changed, 67 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> > > index a94e9b4..f13cf45 100644
> > > --- a/QMP/qmp-events.txt
> > > +++ b/QMP/qmp-events.txt
> > > @@ -188,3 +188,51 @@ Example:
> > >  
> > >  Note: If action is "reset", "shutdown", or "pause" the WATCHDOG event is
> > >  followed respectively by the RESET, SHUTDOWN, or STOP events.
> > > +
> > > +VIRTIO_SERIAL
> > > +-------------
> > 
> >  It should be VIRTIO_SERIAL_ADD.
> 
> What about other events that VIRTIO_SERIAL generates?

 We don't address this problem currently, maybe an integration with qdev
will do, but I have to think more about it.

> Should they have a different event by themselves?

 With the current code, yes. But would be good to avoid it until we have
a proper solution.

> Or should they ride on top of VIRTIO_SERIAL and mention different
> 'operations' that caused the event?

 I'd prefer having a different name if it's a different event, at least
this is how we've done it so far.

> > > +
> > > +- "result": The result of the operation {json-string}
> > > +      This is one of the following:
> > > +         "pass", "fail"
> > 
> >  "result" could be a boolean "success".
> 
> OK; success/fail? Also, by boolean, do you mean the data type? How is
> that represented?

 In JSON it's true/false. In our parser you can use '%i' with integers,
undocumented, yes, sorry for that.





reply via email to

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