Re: [Qemu-devel] RFC adding ioctl's to virtserial/virtconsole

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/03/2010 03:41 PM, Gerd Hoffmann wrote:
> 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?

Yes.

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

That would be really helpful!

Regards,

Anthony Liguori

> cheers,
>   Gerd
>