qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Import KVM headers including Makefile andimpo


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] Import KVM headers including Makefile andimportscript
Date: Mon, 04 May 2009 10:59:20 +0300
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]