From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tsbwn-0003OZ-EA for qemu-devel@nongnu.org; Tue, 08 Jan 2013 11:22:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tsbwm-0001wY-54 for qemu-devel@nongnu.org; Tue, 08 Jan 2013 11:22:41 -0500 Received: from cantor2.suse.de ([195.135.220.15]:34588 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tsbwl-0001wL-SD for qemu-devel@nongnu.org; Tue, 08 Jan 2013 11:22:40 -0500 Message-ID: <50EC47CB.7070705@suse.de> Date: Tue, 08 Jan 2013 17:22:35 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <4773138dce3a8e61f90ebc20837ff4a283137eb3.1357607262.git.agarcia@igalia.com> <50EC256C.5060607@suse.de> <20130108155754.GA25155@igalia.com> In-Reply-To: <20130108155754.GA25155@igalia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 1/2] Add TEWS TPCI200 IndustryPack emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: Blue Swirl , Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org Am 08.01.2013 16:57, schrieb Alberto Garcia: > On Tue, Jan 08, 2013 at 02:55:56PM +0100, Andreas F=E4rber wrote: >=20 >> IPACK_DEVICE() >> >> You have them defined in the header, please use them consistently. >> >> Also, please avoid accessing internals like &s->bus.qbus >> (BUS(s->bus)) or &s->dev.qdev (DEVICE(s->dev)). >=20 > Ok, I'm using all the defined macros and replaced all instances of > DO_UPCAST() with their checked equivalents. >=20 > I also removed all accesses to internals. >=20 > And I defined ipack_bus_new_inplace() (in the spirit of > pci_bus_new_inplace()) and updated tpci200_initfn(). >=20 > Tell me if there's anything else I should change, else I can post the > new patches. Haven't looked at the latest 2/2 patch yet, same might apply there. Otherwise no issues spotted in 1/2. >> Another thing to check (could be a follow-up) is whether the initfn >> can be split into instance_init (e.g., pci_set_*?) and initfn. >=20 > What's exactly that for in this case? QOM realize. My recent RFC only touched ISA but PCI will have to be converted at some point as well: instance_init can do any trivial field initializations (that cannot fail), whereas initfn / realizefn will be run after any management interactions (and might be unrealized and realized again - that's Advanced Magic though). If you don't spot anything obvious then better get the device in first, it's not yet urgent= . Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg