From: Anthony Liguori <aliguori@us.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] Import KVM headers including Makefile andimportscript
Date: Sun, 03 May 2009 16:59:59 -0500 [thread overview]
Message-ID: <49FE13DF.4010205@us.ibm.com> (raw)
In-Reply-To: <49FDB603.6010603@redhat.com>
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.
> Hacks are not good. I'd avoid them whenever possible. Just as an
> example, we'll need to hack the hack whenever we add an architecture
> (ia64, s390, arm...).
It's purely aesthetic for me and I don't mind changing it.
>>
>> The fixup certainly can be made more readable. For instance:
>>
>> # Expand asm/ includes to avoid having to do symlink trickery
>> s:^#include <asm/kvm\(.*\)>$:\
>> #if defined(__x86_64__) || defined(__i386__) \
>> #include <asm-x86/kvm\1> \
>> #elif defined(__powerpc__) \
>> #include <asm-powerpc/kvm\1> \
>> #endif\
>> :g
>>
> 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.
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.
--
Regards,
Anthony Liguori
next prev parent reply other threads:[~2009-05-03 22: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 ` Anthony Liguori [this message]
2009-05-04 7:59 ` [Qemu-devel] [PATCH] Import KVM headers including Makefile andimportscript Avi Kivity
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=49FE13DF.4010205@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=avi@redhat.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).