From: Laszlo Ersek <lersek@redhat.com>
To: Eric Blake <eblake@redhat.com>,
qemu-devel@nongnu.org, mprivozn@redhat.com, kraxel@redhat.com,
amit.shah@redhat.com, lcapitulino@redhat.com
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 [thread overview]
Message-ID: <53AC2268.2000503@redhat.com> (raw)
In-Reply-To: <53AC0D67.7040402@redhat.com>
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 <lersek@redhat.com>
>> ---
>>
>
>> ##
>> -{ '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
next prev parent reply other threads:[~2014-06-26 13:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 11:11 [Qemu-devel] [PATCH for-2.1 v2 0/2] help libvirt know what's up with qga Laszlo Ersek
2014-06-26 11:11 ` [Qemu-devel] [PATCH for-2.1 v2 1/2] virtio-serial: report frontend connection state via monitor Laszlo Ersek
2014-06-26 12:15 ` Eric Blake
2014-06-26 11:11 ` [Qemu-devel] [PATCH for-2.1 v2 2/2] char: report frontend open/closed state in 'query-chardev' Laszlo Ersek
2014-06-26 12:09 ` Eric Blake
2014-06-26 13:38 ` Laszlo Ersek [this message]
2014-06-26 15:09 ` Eric Blake
2014-06-26 11:30 ` [Qemu-devel] [PATCH for-2.1 v2 0/2] help libvirt know what's up with qga Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53AC2268.2000503@redhat.com \
--to=lersek@redhat.com \
--cc=amit.shah@redhat.com \
--cc=eblake@redhat.com \
--cc=kraxel@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mprivozn@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.