From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0t5m-0006RR-Lq for qemu-devel@nongnu.org; Mon, 04 May 2009 04:00:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0t5i-0006LY-2P for qemu-devel@nongnu.org; Mon, 04 May 2009 04:00:02 -0400 Received: from [199.232.76.173] (port=36948 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0t5h-0006LD-So for qemu-devel@nongnu.org; Mon, 04 May 2009 03:59:57 -0400 Received: from mx20.gnu.org ([199.232.41.8]:14911) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M0t5h-0000Zb-9y for qemu-devel@nongnu.org; Mon, 04 May 2009 03:59:57 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0t5g-0000BR-K6 for qemu-devel@nongnu.org; Mon, 04 May 2009 03:59:56 -0400 Message-ID: <49FEA058.2020404@redhat.com> Date: Mon, 04 May 2009 10:59:20 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Import KVM headers including Makefile andimportscript References: <1241298173-20668-1-git-send-email-aliguori@us.ibm.com> <49FD341C.8030205@redhat.com> <49FDB2FF.3060001@us.ibm.com> <49FDB603.6010603@redhat.com> <49FE13DF.4010205@us.ibm.com> In-Reply-To: <49FE13DF.4010205@us.ibm.com> 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 Liguori Cc: qemu-devel@nongnu.org, Hollis Blanchard Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >>>> Can we put them under kvm/, as include/ looks like a generic >>>> include directory, which this isn't. Also, this generates a >>>> gratuitous conflict with qemu-kvm.git, and we have enough of those >>>> already. >>> >>> I'd rather put them under linux/ because right now, we depend on a >>> number of Linux headers (for USB pass through, for instance). >>> >>> The qemu-kvm.git layout is kvm/kernel/include. That doesn't seem to >>> make a lot of sense for QEMU. >> >> linux/ makes sense. But let's coordinate the change. > > BTW, the next logic step for qemu-kvm.git is to move /libkvm/libkvm.c > to /libkvm-all.c, then move /libkvm/libkvm-.c to > /target-/libkvm.c. Then make each target that supports kvm > depend on libkvm-all.o and libkvm.o. kvmctl can be moved to the > top-level too and treated like another qemu tool. The trick is to > build a kvmctl-libkvm.o or something like that but it should be too > difficult. My plan for kvmctl is to port the tests to 'qemu -kernel' and retire it. We can use standard serial or virtio-console for logging. We'll need some fake devices for the testing, but they'd all be very simple. Given that, we can start porting things from libkvm to kvm-all.c and eventually remove it. >> Let's avoid it altogether (we can avoid the compiler.h hack by adding >> a dummy ). > > I still think a fixup is needed because once concern I have is that > it's far too brittle in its current state. It's too easy to not pull > in a header and end up using /usr/include/linux/foo.h. This could > lead to very subtle build errors that would be host OS dependent. Not to mention, libc would see a mix of the newer kernel headers and the system kernel headers. > So I'm thinking that a common prefix to avoid confusion is warranted. > So the fixup would become: > > s:^#include :#include "host/linux/\1":g > s:^#include :#include "host/asm/\1":g > > And we'd change all the existing #includes to use "host/foo". I think > that would make it much more robust. > But pretty ugly :(; maybe we can find a cleaner solution. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.