From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59748 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q23Gl-0008HZ-3r for qemu-devel@nongnu.org; Tue, 22 Mar 2011 11:13:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q23Gh-0003Ex-0n for qemu-devel@nongnu.org; Tue, 22 Mar 2011 11:13:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47236 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q23Gg-0003Ei-QW for qemu-devel@nongnu.org; Tue, 22 Mar 2011 11:13:10 -0400 Message-ID: <4D88BC85.9040602@suse.de> Date: Tue, 22 Mar 2011 16:13:09 +0100 From: Alexander Graf MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH V11 00/15] Xen device model support References: <1299004529-31290-1-git-send-email-anthony.perard@citrix.com> <4D88B0C6.6040506@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony PERARD Cc: Xen Devel , QEMU-devel , Stefano Stabellini On 03/22/2011 03:47 PM, Anthony PERARD wrote: > On Tue, Mar 22, 2011 at 14:23, Alexander Graf wrote: >> On 03/01/2011 07:35 PM, anthony.perard@citrix.com wrote: >>> From: Anthony PERARD >>> >>> Hi all, >>> >>> Here is the few change since the V10: >>> >>> - Add braces for blocks with single statement in the clean-up patch; >>> - the patch that builds Xen only for x86 have been removed, instead, >>> xen_domainbuild is built with libhw and other Xen files are built for >>> i386 >>> target only; >>> - the redirection structure with function pointer have been removed, >>> instead, >>> there are few #define or static inline function use for the >>> compatibility; >> ARGH! >> >> The point of the redirection structure was so I can plug in with xenner and >> replace all the xen calls with in-qemu versions. If you remove it, I'll have >> to put it back in in the xenner patch set :(. >> >> We need some sort of abstraction between calling xs_ functions and actually >> calling them. Wrapping all xs_ calls in static inlines would be fine for >> that, as would the indirect calling table. > As my series doesn't change a lot of things in the xen code, I think > it is better than you put it back in your patch set. Ok, I'll try to see if I can get things based on top of your patch set, then do actual code review. Alex