From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHREh-0007x2-NQ for qemu-devel@nongnu.org; Wed, 13 Aug 2014 01:36:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHRES-0000G5-JV for qemu-devel@nongnu.org; Wed, 13 Aug 2014 01:36:35 -0400 Received: from ozlabs.org ([103.22.144.67]:51431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHRES-0000FL-7i for qemu-devel@nongnu.org; Wed, 13 Aug 2014 01:36:20 -0400 Date: Wed, 13 Aug 2014 13:32:55 +1000 From: David Gibson Message-ID: <20140813033255.GH7628@voom.redhat.com> References: <1407594349-9291-1-git-send-email-eric.auger@linaro.org> <1407594349-9291-6-git-send-email-eric.auger@linaro.org> <20140812024147.GD23065@voom.redhat.com> <53E9BA2A.8040209@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EemXnrF2ob+xzFeB" Content-Disposition: inline In-Reply-To: <53E9BA2A.8040209@linaro.org> Subject: Re: [Qemu-devel] [PATCH v5 05/10] hw/vfio/pci: split vfio_get_device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Auger Cc: peter.maydell@linaro.org, kim.phillips@freescale.com, eric.auger@st.com, joel.schopp@amd.com, patches@linaro.org, will.deacon@arm.com, qemu-devel@nongnu.org, a.rigo@virtualopensystems.com, Bharat.Bhushan@freescale.com, agraf@suse.de, alex.williamson@redhat.com, stuart.yoder@freescale.com, a.motakis@virtualopensystems.com, kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org --EemXnrF2ob+xzFeB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2014 at 08:54:34AM +0200, Eric Auger wrote: > On 08/12/2014 04:41 AM, David Gibson wrote: > > On Sat, Aug 09, 2014 at 03:25:44PM +0100, Eric Auger wrote: > >> vfio_get_device now takes a VFIODevice as argument. The function is sp= lit > >> into 4 functional parts: dev_info query, device check, region populate > >> and interrupt populate. the last 3 are specialized by parent device and > >> are added into DeviceOps. > >=20 > > Why is splitting these up into 4 stages useful, rather than having a > > single sub-class specific callback? >=20 > Hi David, >=20 > VFIOPlatformDevice already inherits from SysBusDevice and hence cannot > inherit from another VFIODevice. Same for VFIOPCIDevice that inherits > from PCIDevice. This is why I created this non QOM struct. But did you > mean something else? Ah, yes, sorry, I missed that, though it's obvious now I think about it. > Then splitting into 4: This was to share some code between platform and > PCI (dev_info query) and vfio_get_device was quite big already. I > thought it makes sense to split it into functional parts. Hm, ok. So splitting out dev_info_query certainly makes sense then. But does splitting the two populate sections make sense? Is it plausible that two different VFIO capable busses would share one of these functions but not the other? --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --EemXnrF2ob+xzFeB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT6txnAAoJEGw4ysog2bOSlOMQAM8wRs0kaK+VnjsHCPskrXpo fbZJNfD/Mf9nqSUxgnGn7p+nzQwrMPEzSH+6q3D29DPBMjXlF5I8yRfWDFVp2f2D do94k7hF3gmBkDShwZerLu9aI39xo7YOMFSnscmb6hZpk3B+0S124T3+bENrqZID O8wutRc7xr4UnuBbjujOYZJe705zny1ttIqPto5TfSD/vUmOwocV2OmR6gdkxcyT e850Z2NJ4TzHjFTPHbS+wACzOVddEzqh7Sh+jDBugdAGa0D+CczG3jkaRFytaplC 5wwdypx8F5JrtqiAuBXirzh82s80yaik5ApcNyw9gq32wHLDu7zQ5Ce/yNU1egZa eNgAPxjV6/EYXASOMKt0dbXhbSK9cYX1zEK57/m99Fuu0uXbXFWSQwnTWgqOFKVQ 9AxPDwsFS2NoJEWa+HZb/BS6bPa9ZnKsY7ab5GkAylBPdswL1G/wl5IF6KCja+TW 6CIHFo4OMqD15Z1mFomN38D6tEO1Dk7OPnicp3FyYEIjAOcnpS5o7onus4qaVGxE 8wve0pZcTblaJaQFq3WLblFHii9Q7uzBVLPokekdu5aI02VuPhTDivYDvHTT6dd2 aI/CqevHxp20jAU0TEJM3gHLT9RVVCGKUQWst3Mtt9QmSNcwSCflJi43MoVwvohv S/pz4JQX3KLnA/fKbTQu =ldXd -----END PGP SIGNATURE----- --EemXnrF2ob+xzFeB--