From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=53651 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OgKcM-0007PD-5I
	for qemu-devel@nongnu.org; Tue, 03 Aug 2010 12:45:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OgKcF-0000Oh-1m
	for qemu-devel@nongnu.org; Tue, 03 Aug 2010 12:45:29 -0400
Received: from mail-qw0-f45.google.com ([209.85.216.45]:64470)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OgKcE-0000Ob-Vv
	for qemu-devel@nongnu.org; Tue, 03 Aug 2010 12:45:23 -0400
Received: by qwf6 with SMTP id 6so101611qwf.4
	for <qemu-devel@nongnu.org>; Tue, 03 Aug 2010 09:45:22 -0700 (PDT)
Message-ID: <4C58479E.2000805@codemonkey.ws>
Date: Tue, 03 Aug 2010 11:45:18 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
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>
In-Reply-To: <4C5846DD.90209@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>, Anthony Liguori <aliguori@redhat.com>, Alon Levy <alevy@redhat.com>, qemu-devel <qemu-devel@nongnu.org>

On 08/03/2010 11:42 AM, Gerd Hoffmann wrote:
>>>> understand what state the session is in.
>>>
>>> Spice would basically (ab-)use it as event delivery mechanism.
>>
>> Can you explain what spice uses these events for?
> Spice would then implement it's own CharServerState and would use it to
>
> 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?

>>> Well. I disagree. Checking the state is needed nevertheless. The
>>> places where virtio-serial checks port->state today it would have to
>>> check whenever port->chardev is non-NULL then. The only difference is
>>> that failures to do so might become a bit more obvious as qemu will
>>> segfault due to the NULL pointer dereferences then. I still think this
>>> isn't worth the effort though.
>>
>> But I think we ultimately need to switch to having the front-ends having
>> a NULL check. Even beyond front-end initiated connect/disconnect,
>> front-end's need to learn to deal with back-end initiated
>> disconnect/connect.
>
> I don't think we have to go with a NULL check.  Providing chr_is_*() 
> functions to query state and adding asserts() to the chr_*() function 
> should provide the same level of robustness IMHO.  Also having 
> CharDriverStates come and go brings its own share of problems.

I think this would be a reasonable solution too.

Regards,

Anthony Liguori