qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.1 v2 2/2] char: report frontend open/close


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH for-2.1 v2 2/2] char: report frontend open/closed state in 'query-chardev'
Date: Thu, 26 Jun 2014 15:38:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 06/26/14 14:09, Eric Blake wrote:
> On 06/26/2014 05:11 AM, Laszlo Ersek wrote:
>> In addition to the on-line reporting added in the previous patch, allow
>> libvirt to query frontend state independently of events.
>>
>> Libvirt's path to identify the guest agent channel it cares about differs
>> between the event added in the previous patch and the QMP response field
>> added here. The event identifies the frontend device, by "id". The
>> 'query-chardev' QMP command identifies the backend device (again by "id").
>> The association is under libvirt's control.
>>
>> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1080376
>> Signed-off-by: Laszlo Ersek <address@hidden>
>> ---
>>
> 
>>  ##
>> -{ 'type': 'ChardevInfo', 'data': {'label': 'str', 'filename': 'str'} }
>> +{ 'type': 'ChardevInfo', 'data': {'label': 'str',
>> +                                  'filename': 'str',
>> +                                  'frontend-open': 'bool'} }
> 
> Hmm; I wonder if this should instead be
> 'frontend-status':'VirtioSerialPortStatus', to reuse the type from patch
> 1/2.  That way, if we ever add a third state, then both the event and
> the poll will be reusing the same enum values to report that state.

I expected this remark :)

The difference is rooted in the fact that the event approaches the
virtio-serial port status from the frontend (ie. guest) side, while the
query approaches the same from the backend (ie. host, chardev) side.

If I wanted to bring those in future-proof sync, then I would have to
change the underlying, generic chardev machinery -- namely, the fe_open
field, and everything that operates on it.

I actually considered the other direction too: rather than introducing
status:VirtioSerialPortStatus, just add open:bool (which was your
original suggestion in your v1 review). I decided against it because the
current list of enum constants (connected, disconnected) expresses just
the same, and it'll be a *tiny* bit easier to extend, should that
necessity arise.

Sounds acceptible? :) If not, then I'm OK to replace
status:VirtioSerialPortStatus with open:bool in the first patch.

Thanks,
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]