From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32785 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PD13e-0005E7-Qw for qemu-devel@nongnu.org; Mon, 01 Nov 2010 16:32:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PD13d-0005rw-J2 for qemu-devel@nongnu.org; Mon, 01 Nov 2010 16:32:46 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:36837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PD13d-0005rp-FX for qemu-devel@nongnu.org; Mon, 01 Nov 2010 16:32:45 -0400 Received: by gya6 with SMTP id 6so3855430gya.4 for ; Mon, 01 Nov 2010 13:32:44 -0700 (PDT) Message-ID: <4CCF23E9.8070404@codemonkey.ws> Date: Mon, 01 Nov 2010 15:32:41 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1288623713-28062-1-git-send-email-agraf@suse.de> <1288623713-28062-29-git-send-email-agraf@suse.de> <4CCEE08F.4030403@codemonkey.ws> <4CCEE463.3090406@codemonkey.ws> <4CCF176F.2020600@redhat.com> <4CCF17EF.8090502@codemonkey.ws> <0A26E838-7FF5-4E4C-98EB-5EB0821460B9@suse.de> In-Reply-To: <0A26E838-7FF5-4E4C-98EB-5EB0821460B9@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Paolo Bonzini , qemu-devel Developers , Gerd Hoffmann On 11/01/2010 02:47 PM, Alexander Graf wrote: > Where else would it belong? Qemu is an emulator. Device emulation belongs to qemu code. The xen PV machine is nothing but a special case of the pc machine with custom firmware and odd devices :). > > As I stated in my cover letter, the goal of all this should be to have the qemu pieces be 100% independent of any xen headers or libraries, I'm not sure I agree with the goal. I think where ever possible we should reuse code with the Xen project when it makes sense. Reusing blkback/netback is impossible because we want userspace implementations and the current implementations are in the kernel. blktap also doesn't tie into the QEMU block layer and making it tie into the QEMU block layer would probably result in more code than it saved. OTOH, xenstored and xenconsoled have very little direct dependence on Xen. I'm not saying that we shouldn't make things Just Work in QEMU, so if that means spawning xenconsoled/xenstored automagically from QEMU with special options, that's perfectly fine. But to replicate the functionality of this code solely because of NIH seems like a waste of effort. Regards, Anthony Liguori > so we can eventually isolate it well enough that it even works on non-x86. Then we're at the point qemu code usually is. > > I'm sure there are also practical implications btw. But I don't really care about those too much, because the architectural ones outweigh that to me. > > > Alex > >