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

[Anthony Liguori <anthony@codemonkey.ws>]

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
>