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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

On 2012-03-26 21:49, Anthony Liguori wrote:
> 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.

But all this is only a problem for these three here (PIT, RTC, HPET) as
their objects shall be embedded into the super-IO. If you only embed an
object pointer, it shouldn't be an issue anymore, no?

Also inheritance is not a problem here as we do not derive from the
three types in question. If there is a super/sub-class relation, those
need to share an internal header, of course.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]