qemu-s390x
[Top][All Lists]
Advanced

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

Re: [PATCH 50/55] s390x/event-facility: Simplify creation of SCLP event


From: Cornelia Huck
Subject: Re: [PATCH 50/55] s390x/event-facility: Simplify creation of SCLP event devices
Date: Tue, 26 May 2020 13:38:36 +0200

On Tue, 26 May 2020 13:23:43 +0200
Paolo Bonzini <address@hidden> wrote:

> On 26/05/20 11:45, Cornelia Huck wrote:
> > On Tue, 19 May 2020 16:55:46 +0200
> > Markus Armbruster <address@hidden> wrote:
> >   
> >> init_event_facility() creates the SCLP events bus with two SCLP event
> >> devices (sclpquiesce and sclp-cpu-hotplug).  It leaves the devices
> >> unrealized.  A comment explains they will be realized "via the bus".
> >>
> >> The bus's realize method sclp_events_bus_realize() indeed realizes all
> >> unrealized devices on this bus.  It carries a TODO comment claiming
> >> this "has to be done in common code".  No other bus realize method
> >> realizes its devices.
> >>
> >> The common code in question is bus_set_realized(), which has a TODO
> >> comment asking for recursive realization.  It's been asking for years.
> >>
> >> The only devices sclp_events_bus_realize() will ever realize are the
> >> two init_event_facility() puts there.
> >>
> >> Simplify as follows:
> >>
> >> * Make the devices members of the event facility instance struct, just
> >>   like the bus.  object_initialize_child() is simpler than
> >>   object_property_add_child() and object_unref().
> >>
> >> * Realize them in the event facility realize method.
> >>
> >> This is in line with how such things are done elsewhere.
> >>
> >> Cc: Cornelia Huck <address@hidden>
> >> Cc: Halil Pasic <address@hidden>
> >> Cc: Christian Borntraeger <address@hidden>
> >> Cc: Richard Henderson <address@hidden>
> >> Cc: David Hildenbrand <address@hidden>
> >> Cc: address@hidden
> >> Signed-off-by: Markus Armbruster <address@hidden>
> >> ---
> >>  hw/s390x/event-facility.c | 59 ++++++++++++++++-----------------------
> >>  1 file changed, 24 insertions(+), 35 deletions(-)  
> > 
> > So, what should happen with this patch? Should it go with the rest of
> > the series, or should it go through the s390 tree?  
> 
> I think an Acked-by is the simplest way to handle it, since qdev_realize
> doesn't exist upstream.

Ok, let's keep them together.

Acked-by: Cornelia Huck <address@hidden>




reply via email to

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