From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRw0J-000879-It for qemu-devel@nongnu.org; Wed, 01 Jun 2011 20:43:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRnAA-0000cW-In for qemu-devel@nongnu.org; Wed, 01 Jun 2011 11:16:56 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:39152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRnA9-0000by-8Z for qemu-devel@nongnu.org; Wed, 01 Jun 2011 11:16:49 -0400 Received: by yxk8 with SMTP id 8so2688345yxk.4 for ; Wed, 01 Jun 2011 08:16:48 -0700 (PDT) Sender: Richard Henderson Message-ID: <4DE657DC.3070909@twiddle.net> Date: Wed, 01 Jun 2011 08:16:44 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1306892315-7306-1-git-send-email-eduard.munteanu@linux360.ro> <1306892315-7306-2-git-send-email-eduard.munteanu@linux360.ro> <4DE64646.3010505@twiddle.net> <4DE64CE4.7030300@redhat.com> In-Reply-To: <4DE64CE4.7030300@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 01/13] Generic DMA memory access interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, kvm@vger.kernel.org, mst@redhat.com, aik@ozlabs.ru, joro@8bytes.org, seabios@seabios.org, qemu-devel@nongnu.org, agraf@suse.de, blauwirbel@gmail.com, yamahata@valinux.co.jp, kevin@koconnor.net, paul@codesourcery.com, Eduard - Gabriel Munteanu , dwg@au1.ibm.com, david@gibson.dropbear.id.au On 06/01/2011 07:29 AM, Avi Kivity wrote: > On 06/01/2011 05:01 PM, Richard Henderson wrote: >> > + err = dev->mmu->translate(dev, addr,&paddr,&plen, is_write); >> >> I see you didn't take my suggestion for using an opaque callback pointer. >> Really and truly, I won't be able to use this as-is for Alpha. >> > > Rather than opaques, please pass the DMA engine itself and use container_of(). The dma engine object is currently sitting in the PCIBus structure. Which is private, and can't be extended by a host bridge implementation. The entire code could be re-arranged, true, but please suggest something reasonable. > We should be removing opaques, not adding them. See my followup elsewhere. Opaques *can* be cleaner than upcasting, particularly if there are too many hoops through which to jump. r~