On Sat, 27 Mar 2010 13:33:22 +0530 Amit Shah <amit.s...@redhat.com> 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.