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: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH 2/2] char: report frontend open/closed state in 'query-chardev'
Date: Wed, 25 Jun 2014 09:02:00 -0400

On Tue, 24 Jun 2014 08:36:36 -0600
Eric Blake <address@hidden> wrote:

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

Has this series being reviewed?



reply via email to

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