From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NwF7X-00054V-VJ for qemu-devel@nongnu.org; Mon, 29 Mar 2010 09:35:12 -0400 Received: from [140.186.70.92] (port=41151 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwF7W-00050X-BL for qemu-devel@nongnu.org; Mon, 29 Mar 2010 09:35:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NwF7T-0001Jn-Er for qemu-devel@nongnu.org; Mon, 29 Mar 2010 09:35:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51171) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwF7T-0001JO-5n for qemu-devel@nongnu.org; Mon, 29 Mar 2010 09:35:07 -0400 Date: Mon, 29 Mar 2010 10:34:58 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed port/device add Message-ID: <20100329103458.261e58e4@redhat.com> In-Reply-To: <20100327080321.GI7039@amit-x200.redhat.com> References: <1269442173-18421-9-git-send-email-amit.shah@redhat.com> <1269442173-18421-10-git-send-email-amit.shah@redhat.com> <1269442173-18421-11-git-send-email-amit.shah@redhat.com> <20100325155541.570f817d@redhat.com> <20100326021628.GI8111@amit-x200.redhat.com> <20100326101402.02e3fffb@redhat.com> <20100326132620.GE7039@amit-x200.redhat.com> <20100326112903.712262b9@redhat.com> <20100326144309.GG7039@amit-x200.redhat.com> <20100326145236.6fd1692b@redhat.com> <20100327080321.GI7039@amit-x200.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: aliguori@us.ibm.com, Juan Quintela , Gerd Hoffmann , qemu list , "Michael S. Tsirkin" On Sat, 27 Mar 2010 13:33:22 +0530 Amit Shah 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.