From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Smil7-0002aY-KR for qemu-devel@nongnu.org; Thu, 05 Jul 2012 05:54:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Smil5-0006LZ-Ue for qemu-devel@nongnu.org; Thu, 05 Jul 2012 05:54:01 -0400 Message-ID: <4FF5642C.5070506@redhat.com> Date: Thu, 05 Jul 2012 11:53:48 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1341422373-13614-1-git-send-email-afaerber@suse.de> <1341422373-13614-15-git-send-email-afaerber@suse.de> <20120704211717.GC27653@redhat.com> <20120704212614.GA27711@redhat.com> <4FF4C4EC.2090404@suse.de> In-Reply-To: <4FF4C4EC.2090404@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 14/14] pci: Tidy up PCI host bridges List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: "Michael S. Tsirkin" , jbaron@redhat.com, Alexander Graf , qemu-devel@nongnu.org, =?ISO-8859-1?Q?Andreas_F=E4rber?= , "\"list@suse.de\"@zmta06.collab.prod.int.phx2.redhat.com:New World" , anthony@codemonkey.ws, open@suse.de Il 05/07/2012 00:34, Andreas F=E4rber ha scritto: >> > Just to clarify: replacing upcasts which are always safe >> > with downcasts which can fail is what I consider especially ugly. > As per Anthony the parent field in the QOM instance structs is not > supposed to be touched (cf. object.h). We mark it /*< private >*/ so > that it doesn't even show up in gtk-doc documentation. If it is unused, > its name becomes irrelevant and could even be "reserved" if we so > wanted. Renaming it to whatever proves that all old references are gone. I disagree with removing static checks whenever possible. > Background is that qdev and QOM work differently with regards to > inheritance: as mentioned in the preceding patch, for qdev the parent > was (had to be) identified by name and could be anywhere in the struct; Not entirely true, being at the beginning of the struct is already enforced by using DO_UPCAST (which is admittedly a strange name for a downcast macro) instead of container_of. > for QOM the parent is a subset of the struct from the start and it's > supposed to be accessed through the struct type that provides the > fields, the usual way to get such a pointer is through > OBJECT_CHECK()-derived cast macros. Paolo