From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCFxq-0001GU-Cl for qemu-devel@nongnu.org; Mon, 26 Mar 2012 15:52:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCFxm-0007YT-3J for qemu-devel@nongnu.org; Mon, 26 Mar 2012 15:52:25 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:43007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCFxl-0007XT-VB for qemu-devel@nongnu.org; Mon, 26 Mar 2012 15:52:22 -0400 Received: by ghrr14 with SMTP id r14so5124577ghr.4 for ; Mon, 26 Mar 2012 12:52:20 -0700 (PDT) Message-ID: <4F70C8F1.4030504@codemonkey.ws> Date: Mon, 26 Mar 2012 14:52:17 -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> In-Reply-To: <4F70C726.9020504@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: Wanpeng Li , "qemu-devel@nongnu.org" , Isaku Yamahata , Avi Kivity , Paolo Bonzini , Gavin Shan 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? Inheritance is the other nasty case. To inherit from a type, you need to have the type definition. This is a pretty common problem with Object systems and the typical solution is PIMPL[1]. So maybe that's the right thing to do here, but that would have a significant affect on the code. That's what I mean by rushing how to handle this. There are multiple possible solutions and they need to be considered. The problem is purely aesthetic too, so I don't see a rush to fix it. [1] http://c2.com/cgi/wiki?PimplIdiom Regards, Anthony Liguori > > Jan