From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0zo9-0001tp-1L for qemu-devel@nongnu.org; Mon, 13 Aug 2012 14:56:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0zo6-0004g7-P1 for qemu-devel@nongnu.org; Mon, 13 Aug 2012 14:56:08 -0400 Received: from katherinewilliamsonsoprano.co.uk ([82.165.34.74]:58420 helo=p15195424.pureserver.info) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0zo6-0004eM-I4 for qemu-devel@nongnu.org; Mon, 13 Aug 2012 14:56:06 -0400 Received: from [149.241.36.29] (helo=[192.168.1.108]) by p15195424.pureserver.info with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1T0zo1-0000qe-LG for qemu-devel@nongnu.org; Mon, 13 Aug 2012 19:56:04 +0100 Message-ID: <50294E05.101@ilande.co.uk> Date: Mon, 13 Aug 2012 19:57:09 +0100 From: Mark Cave-Ayland MIME-Version: 1.0 References: <1343872026-18189-1-git-send-email-afaerber@suse.de> <1343872026-18189-15-git-send-email-afaerber@suse.de> <20120813131659.GE16801@redhat.com> <87obme5135.fsf@codemonkey.ws> In-Reply-To: <87obme5135.fsf@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-1.2 v5 14/14] pci: Tidy up PCI host bridges List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 13/08/12 15:16, Anthony Liguori wrote: > I understand what your objection is but it's unreasonable IMHO. The > purpose of QOM is to bring consistency across large swaths of code in > QEMU that have historically done things there own way. > > This means expressing concepts like inheritence and casting in the same > way across the board. The common way (the QOM way) is to make the > parent type the first member of the struct (typically named parent or > parent_obj) and then to use cast macros to upcast and downcast. > > This patch is 100% correct in that regard and I'm going to apply it once > Andreas makes the change I requested. > > For my part, I'm long over due in writing up a device authoring style > guide that I promised a few weeks ago. I'll write that up this > afternoon and send it out today. > > We can debate the merits of this sort of thing in the style guide. Yes please! I've spent quite a fair bit of time over the past couple of weeks in this area, and have found the lack of documentation related to trying to create a new hardware device fairly frustrating. The hardest part is not the coding, but figuring which of the following I should be using out of: qom qdev qmp hmp sysbus VMState (I think that half of these are now obsolete interfaces, but a general document which explains how these things are related and which ones I should be using would be very welcome) ATB, Mark.