From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel@nongnu.org, Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] Import KVM headers including Makefile andimportscript
Date: Mon, 04 May 2009 10:59:20 +0300 [thread overview]
Message-ID: <49FEA058.2020404@redhat.com> (raw)
In-Reply-To: <49FE13DF.4010205@us.ibm.com>
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-<arch>.c to
> /target-<arch>/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 <linux/compiler.h>).
>
> 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 <linux/\(.*\)>:#include "host/linux/\1":g
> s:^#include <asm/\(.*\)>:#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.
next prev parent reply other threads:[~2009-05-04 8:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-02 21:02 [Qemu-devel] [PATCH] Import KVM headers including Makefile and import script Anthony Liguori
2009-05-02 21:04 ` [Qemu-devel] " Anthony Liguori
2009-05-03 6:05 ` [Qemu-devel] " Avi Kivity
2009-05-03 15:06 ` [Qemu-devel] [PATCH] Import KVM headers including Makefile andimport script Anthony Liguori
2009-05-03 15:19 ` Avi Kivity
2009-05-03 21:59 ` [Qemu-devel] [PATCH] Import KVM headers including Makefile andimportscript Anthony Liguori
2009-05-04 7:59 ` Avi Kivity [this message]
2009-05-03 15:29 ` [Qemu-devel] [PATCH] Import KVM headers including Makefile and import script Avi Kivity
2009-05-03 22:02 ` [Qemu-devel] [PATCH] Import KVM headers including Makefile andimport script Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49FEA058.2020404@redhat.com \
--to=avi@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=hollisb@us.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).