From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCH1Q-0006hC-6a for qemu-devel@nongnu.org; Mon, 26 Mar 2012 17:00:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCH1O-0004KV-9u for qemu-devel@nongnu.org; Mon, 26 Mar 2012 17:00:11 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:60838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCH1O-0004JV-4o for qemu-devel@nongnu.org; Mon, 26 Mar 2012 17:00:10 -0400 Received: by obbwd20 with SMTP id wd20so6477838obb.4 for ; Mon, 26 Mar 2012 14:00:08 -0700 (PDT) Message-ID: <4F70D8D5.8040608@codemonkey.ws> Date: Mon, 26 Mar 2012 16:00:05 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1332727608-26523-1-git-send-email-liwp@linux.vnet.ibm.com> <4F705F08.4010002@siemens.com> <4F70A877.3060809@codemonkey.ws> <4F70C3E0.4000708@web.de> <4F70C4F6.8090900@codemonkey.ws> <4F70C55D.4030203@web.de> <4F70C5FA.4060605@codemonkey.ws> <4F70C726.9020504@web.de> <4F70C850.5030602@codemonkey.ws> <4F70CD2A.3040802@web.de> <4F70CDD4.2090903@codemonkey.ws> <4F70D1F0.20102@web.de> In-Reply-To: <4F70D1F0.20102@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Gavin Shan , "qemu-devel@nongnu.org" , Isaku Yamahata , Avi Kivity , Paolo Bonzini , Wanpeng Li On 03/26/2012 03:30 PM, Jan Kiszka wrote: > 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. It's more complicated than that because it's a tree, not a graph. So there may be additional references held beyond the parent. >>> 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. I don't fundamentally disagree with anything you're saying here. I'm only pointing out that (1) it's not a trivial problem and (2) it's not an urgent problem. Regards, Anthony Liguori > > Jan