From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47632 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgOIm-0006eS-55 for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:41:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgOIh-0003Cl-3f for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:41:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32578) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgOIg-0003Cf-Rq for qemu-devel@nongnu.org; Tue, 03 Aug 2010 16:41:27 -0400 Message-ID: <4C587EE9.3070306@redhat.com> Date: Tue, 03 Aug 2010 22:41:13 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] RFC adding ioctl's to virtserial/virtconsole References: <1998763220.603051280770128553.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> <4C5703A1.2040500@codemonkey.ws> <4C57D768.20401@redhat.com> <4C5815BC.6030600@codemonkey.ws> <4C583594.8060903@redhat.com> <4C5839D0.1060109@codemonkey.ws> <4C5846DD.90209@redhat.com> <4C58479E.2000805@codemonkey.ws> <4C584B8D.6090405@redhat.com> <4C58577C.90408@codemonkey.ws> In-Reply-To: <4C58577C.90408@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , Anthony Liguori , Alon Levy , qemu-devel On 08/03/10 19:53, Anthony Liguori wrote: > On 08/03/2010 12:02 PM, Gerd Hoffmann wrote: >> On 08/03/10 18:45, Anthony Liguori wrote: >>> On 08/03/2010 11:42 AM, Gerd Hoffmann wrote: >>>> spice-vmc code registers/unregisters the interface within the spice >>>> server. So the interface is only activated in case the guest uses it. >>>> Spice client sees the interface being active or not and can act >>>> accordingly. >>> >>> So we have to migrate connected state? >> >> virtio-serial handles that already. > > And we have to propagate this upon load to the char device backend. Happens too, by calling port->guest_open() if needed in loadvm_post(). > Do we assume that the chardev is in the CONNECTED state initially? If we > do a loadvm at run time while we're in the CONNECTED state, do we > generate a DISCONNECTED followed by CONNECTED state transition? If we > loadvm to a state where we were in the DISCONNECTED state, does that > generate DISCONNECTED followed by CONNECTED followed by DISCONNECTED or > just DISCONNECTED? > > This is exactly the type of problem that we've had in the past by not > having an API that clearly forces management of life cycle. That indeed must be cleanly defined and for best results also enforced in some way, say using asserts(). That needs some bigger planning and not some ad-hoc "Oh lets us quickly add this" patching though. When re-designing chardevs I wanna do it once and wanna do it right. Are there BoF slots @ kvm forum? I can try to put together something (current pain points + feature wishlist + better chardev data structures + better chardev api) to kick a discussion either in Boston or at qemu-devel. Will take some time though. cheers, Gerd