qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] char: report frontend open/closed state in


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 2/2] char: report frontend open/closed state in 'query-chardev'
Date: Tue, 24 Jun 2014 08:36:36 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

[cc'ing Luiz]

On 06/24/2014 08:21 AM, Laszlo Ersek wrote:
> On 05/29/14 23:05, Eric Blake wrote:
>> On 05/29/2014 02:43 PM, Laszlo Ersek wrote:

>>> In this series I try to implement the ideas that (I believe) were
>>> suggested by Gerd and Amit in
>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1080376>.
>>> 
>>> When the guest agent exits or dies (disconnects from the virtio-serial
>>> port), the backend (eg. a host-side unix domain socket) doesn't (in
>>> general, can't) reflect it. This lack of info tends to trip up libvirt
>>> in some cases, waiting indefinitely for an agent that doesn't exist.
>>> 
>>> The series adds two monitor events that report about virtio-serial ports
>>> being opened and closed (for online notification), and extends the
>>> "query-chardev" QMP command's return type with a "frontend_open" bool
>>> (for querying at late libvirt startup).

>>
>>>>> +#                 backend (eg. with the chardev=... option) is in open or
>>>>> +#                 closed state (since 2.2)
>>>>
>>>> Why 2.2? Are you saying it is too late to make the 2.1 soft freeze?
>>>
>>> I thought that reviewers would immediately question the direction of the
>>> patchset (ie. monitor events + new query field), and not just suggest
>>> tweaks; so 2.2 seemed safer. Perhaps I can make it till the 2.1 soft
>>> freeze (June 17th), but that depends (as I've learned now) on Wenchao's
>>> series too.
>>
>> Actually, I think your series and Wenchao's are mostly orthogonal -
>> either could go in first, and it's just fine if one hits 2.1 while the
>> other waits till 2.2.  It's just a matter of code churn, where getting
>> both in means whoever is second has to consider the code added in the
>> meantime (either your series is tweaked to use the qapi generation, or
>> Wenchao's series is tweaked to convert "one" more event).
> 
> I'm thinking about resuming work on this. Wenchao's series has been
> applied (ends at commit 75175173). We're between soft and hard freeze
> now. Should I aim at 2.1 or 2.2?

This series was posted before soft freeze, but adds a new feature.  If
we're going to get it in the 2.1 release, it must be before hard freeze.
 I'll leave it up to Luiz whether a QMP addition this late in the game
is safe to take, although my personal opinion is that since it was
proposed before soft freeze, and DOES make life easier for libvirt, it
is worth a strong consideration.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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