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

[Amit Shah <amit.shah@redhat.com>]

On (Fri) Mar 26 2010 [14:52:36], Luiz Capitulino wrote:
> > >  My suggestion for the immediate term is to do what we have been doing so
> > > far, ie. call it VIRTIO_SERIAL_ADD. Worst case here is: we add a new way
> > > to group events which requires a new VIRTIO_SERIAL event, in this case we
> > > could emit both, the new VIRTIO_SERIAL and the old VIRTIO_SERIAL_ADD. The
> > > latter would be deprecated too.
> > 
> > I've no problem doing it either way - whatever you prefer is fine.
> > 
> > BTW these are two distinct events already - failure in initialising a
> > device and failure in initialising a port. Do you think these should be
> > separate as well?
> 
>  That depends on what you want clients to know/do about it.
> 
>  Can ports and devices be added and work independently of each other?
> Why is it relevant for a client to know that a _device_ has failed to
> initialize?

I'm not sure what you mean by a client, but let's say libvirt handles
the qemu session. A single device can have multiple ports. If a device
fails to register *in the guest*, all the ports associated with that
device could be hot-unplugged on the host to reduce host resource usage.

If just a single port fails to register *in the guest*, libvirt may just
want to hot-unplug it to free up resources.

So yes, I think both are necessary.

Anyway, I guess the answer is to split both these events.

>  If clients connect to a port and all they need to know is "Sorry, but
> that port won't be available", then you don't even need to have a port/device
> distinction in the event.
> 
>  Also note that events can be improved to include more information later,
> if needed. So, the best approach is to include as less information as
> possible (given that it satisfies current client needs, of course).

Right; that's the reason only the failing port number is given right
now.

> > >  Or, if you can wait I can _try_ to solve this problem next week, although
> > > I have no idea how hard this is going to be.
> > 
> > I think it's cleaner to club everything; but basically I'll go with
> > whatever you say. I've no problem waiting.
> 
>  It's definitely needed to group events some way, we just have to
> find a good way to do it. Having each subsystem doing it its own way
> is not what we want because of protocol consistency and related
> problems.

Yes, that's exactly why I think waiting till you iron it out would help.

		Amit