[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 012/136] arm/cubieboard: use memdev for RAM
From: |
Peter Maydell |
Subject: |
Re: [PULL 012/136] arm/cubieboard: use memdev for RAM |
Date: |
Mon, 2 Mar 2020 17:11:48 +0000 |
On Mon, 2 Mar 2020 at 16:55, Igor Mammedov <address@hidden> wrote:
>
> On Mon, 2 Mar 2020 15:41:13 +0000
> Peter Maydell <address@hidden> wrote:
> > Hi Igor, I just noticed this, and I don't think it's the
> > right thing. The board model should have its own state
> > structure which contains any objects it creates. Just
> > because there happens currently to be only a single
> > object in this case doesn't mean we want to lose the
> > structure. In particular, we now just leak the
> > pointer to the TYPE_AW_A10 object, rather than having
> > it be tracked by being pointed to from the MachineState.
> > Being able to avoid just leaking pointers to objects like
> > that is one of the reasons I like having a MachineState now.
> The reason why this structure was removed was that it wasn't
> MachineState object but a random structure which was a common
> pattern in pre-QOM qemu.
>
> Code was allocating 's', assigning pointer to s->a10 member and
> then happily loosing both pointers in the end.
Oh, so it was -- I misread the code.
> I can convert it to MachineState derived board as
> an example to follow.
No, you don't need to do that, I hadn't realized it
wasn't already MachineState derived, because it looked
superficially like it was. Apologies for the false alarm.
thanks
-- PMM