qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4] qdev: DEVICE_DELETED event


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v4] qdev: DEVICE_DELETED event
Date: Mon, 11 Mar 2013 21:35:45 +0200

On Mon, Mar 11, 2013 at 02:26:58PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
> 
> > On Fri, Mar 08, 2013 at 07:36:28AM -0600, Anthony Liguori wrote:
> >> Markus Armbruster <address@hidden> writes:
> >> 
> >> > "Michael S. Tsirkin" <address@hidden> writes:
> >> >
> >> >> On Thu, Mar 07, 2013 at 08:57:52PM +0100, Markus Armbruster wrote:
> >> >>> "Michael S. Tsirkin" <address@hidden> writes:
> >> >>> 
> >> >>> > libvirt has a long-standing bug: when removing the device,
> >> >>> > it can request removal but does not know when the
> >> >>> > removal completes. Add an event so we can fix this in a robust way.
> >> >>> >
> >> >>> > Signed-off-by: Michael S. Tsirkin <address@hidden>
> >> >>> 
> >> >>> Speaking as the acting QMP maintainer, just to avoid misunderstandings:
> >> >>> there's disagreement on the event's design, namely when it should fire,
> >> >>> and how it should name the device.  I don't want the discussion
> >> >>> preempted by a commit.
> >> >>
> >> >> Yes, you are asking for more functionality, but can I add this in a
> >> >> follow-up commit please?  I prefer this patch as is, as it can be
> >> >> backported to stable branches and downstreams.  Upstream a follow up
> >> >> patch can add fields and more triggers which won't apply to any
> >> >> downstreams.
> >> >
> >> > If you want to address my review comments in a separate patch, go right
> >> > ahead.  Please post both together as a series, for coherent review and
> >> > to simplify patch tracking.
> >> >
> >> > I'm asking for two things:
> >> >
> >> > 1. Event member path.  Fair to call this "more functionality".  I agree
> >> >    that backporting it to pre-QOM versions isn't practical.
> >> >
> >> > 2. Sane event trigger condition: on any device deletion, not just when
> >> >    the device happens to have a qdev ID.  This isn't "more", it's
> >> >    "different".
> >> 
> >> Ack.
> >> 
> >> Regards,
> >> 
> >> Anthony Liguori
> >
> >
> > So how does one get the path that you require?
> >
> > ERROR:qom/object.c:1011:object_get_canonical_path: assertion failed:
> > (prop != NULL)
> 
> Can you share your patch?  This means something is wrong.  All devices
> have a canonical path.
> 
> Regards,
> 
> Anthony Liguori

I figured it out - we were trying to get the path after the device was
detached from the parent. We'll just have to calculate the path before
unparenting and pass it in.

-- 
MST



reply via email to

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