[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH v2 3/4] ppc/pnv: introduce Pnv8Chip and Pnv9Chip m

From: David Gibson
Subject: Re: [Qemu-ppc] [PATCH v2 3/4] ppc/pnv: introduce Pnv8Chip and Pnv9Chip models
Date: Wed, 20 Jun 2018 10:56:22 +1000
User-agent: Mutt/1.10.0 (2018-05-17)

On Tue, Jun 19, 2018 at 07:24:44AM +0200, Cédric Le Goater wrote:
> >>>  typedef struct PnvChipClass {
> >>>      /*< private >*/
> >>> @@ -75,6 +95,7 @@ typedef struct PnvChipClass {
> >>>  
> >>>      hwaddr       xscom_base;
> >>>  
> >>> +    void (*realize)(PnvChip *chip, Error **errp);
> >>
> >> This looks the wrong way round from how things are usually done.
> >> Rather than having the base class realize() call the subclass specific
> >> realize hook, it's more usual for the subclass to set the
> >> dc->realize() and have it call a k->parent_realize() to call up the
> >> chain.  grep for device_class_set_parent_realize() for some more
> >> examples.
> >
> > Ah. That is more to my liking. There are a couple of models following
> > the wrong object pattern, xics, vio. I will check them.
> So XICS is causing some head-aches because the ics-kvm model inherits
> from ics-simple which inherits from ics-base. so we have a grand-parent
> class to handle.

Ok.  I mean, we should probably switch ics around to use the
parent_realize model, rather than the backwards one it does now.  But
it's not immediately obvious to me why having a grandparent class
breaks things.

> if we could affiliate ics-kvm directly to ics-base it would make the 
> family affair easier. we need to check migration though.

But that said, I've been thinking for a while that it might make sense
to fold ics-kvm into ics-base.  It seems very risky to have two
different object classes that are supposed to have guest-identical
behaviour.  Certainly adding any migratable state to one not the other
would be horribly wrong.

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

Attachment: signature.asc
Description: PGP signature

reply via email to

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