qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to ta


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM
Date: Mon, 26 Mar 2012 22:30:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-03-26 22:13, Anthony Liguori wrote:
> On 03/26/2012 03:10 PM, Jan Kiszka wrote:
>> On 2012-03-26 21:49, Anthony Liguori wrote:
>>> On 03/26/2012 02:44 PM, Jan Kiszka wrote:
>>> 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?
> 
> The reference counting stuff obviously needs to be looked at even in
> this case.

A composite object is owned by its container. So it should go when the
container leaves.

> 
>> 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.
> 
> Yes, but then you have two headers for every type.  Is that really a
> good thing?

It's cleaner and more explicit than tagging members with comments. And
it's nothing we will have for each and every type as only a small subset
is actually inheriting, the mass is finalizing.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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