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

[Luiz Capitulino]

On Sat, 27 Mar 2010 13:33:22 +0530
Amit Shah <address@hidden> wrote:

> 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.

 Client is any application talking to QEMU through QMP.

> 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.

 Yes, that makes sense.

[...]

> > > >  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.

 Ok.