Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 02:44 PM, Jan Kiszka wrote:
> On 2012-03-26 21:39, Anthony Liguori wrote:
> > On 03/26/2012 02:37 PM, Jan Kiszka wrote:
> > > On 2012-03-26 21:35, Anthony Liguori wrote:
> > > > > > Since this is an easily refactorable thing to look at later, I think
> > > > > > we should
> > > > > > start with extracting the types.
> > > > >
> > > > > My worry is that those three refactorings set bad examples for others.
> > > > > So I'd like to avoid such back and forth if possible.
> > > >
> > > > I'm not really worried about it.  It's so easier to refactor this
> > > > later.  Why rush it now?
> > >
> > > You rush changing the current layout, not me. :)
> >
> > No, I'm trying to do incremental changes without boiling the ocean in
> > the process.
> >
> > I think we all are in violent agreement about where we want to end up
> > (as opaque types as possible).  I don't want to hold back additional
> > refactoring on doing this right (and it's not just a matter of
> > malloc/free).
>
> Either I'm missing it in the code shuffling, or it's not part of this
> series: Can you point out where more that a forward reference and
> malloc/free is needed?

QOM is built around the concept that the type size is know (as is GObject). 
type_initialize() assumes that the pointer passed is an adequate size.

You would either need to move to a model where the memory was completely owned 
by QOM (which would mean folding type_new into type_initialize) or have a way to 
query instance size for a given type.

This would also mean that reference counting should be revisited although with 
how dereferencing a parent affects the child.

It's not rocket science, but it's also something that needs to be done 
carefully.

Regards,

Anthony Liguori

> Jan