On Mon, May 04, 2009 at 08:13:16AM -0500, Anthony Liguori wrote:
> We can not just rely on everyone who uses QEMU to use the latest version
> of Debian...
>
> The fact is, linux-libc-dev is *not* meant for applications to use as
> the official kernel ABI. We shouldn't depend on it.
Actually I
On Mon, May 04, 2009 at 08:13:16AM -0500, Anthony Liguori wrote:
> The fact is, linux-libc-dev is *not* meant for applications to use as
> the official kernel ABI. We shouldn't depend on it.
Umm, it is. That's exactly the reason what it is for. Note that the
name of the package varies dependin
On Mon, May 04, 2009 at 08:15:58AM -0500, Anthony Liguori wrote:
> Edgar E. Iglesias wrote:
>> I don't feel very strongly about it but my gut feeling tells me we
>> shouldn't be doing this.
>>
>
> We have to. It's not just KVM, it's virtio, tun/tap, and as we add more
> things to the Linux ker
Avi Kivity wrote:
At least on Fedora, kernel-headers is. It is installed in
/usr/include/linux and is synced (sorta) to the installed kernel.
It's not the case with Ubuntu.
Carrying a subset of kernel headers is a bit too much, IMO.
Carrying virtio, kvm, and if_tun would be sufficient IMO.
Anthony Liguori wrote:
Stefan Weil wrote:
Anthony Liguori schrieb:
For Debian systems, those headers are installed by package
linux-libc-dev.
There are also packages for cross compilation in emdebian
(linux-libc-dev-mips-cross, linux-libc-dev-powerpc-cross, ...).
Yes, those headers did not
Edgar E. Iglesias wrote:
I don't feel very strongly about it but my gut feeling tells me we
shouldn't be doing this.
We have to. It's not just KVM, it's virtio, tun/tap, and as we add more
things to the Linux kernel to support QEMU, it'll just grow larger.
This is how applications are su
Avi Kivity wrote:
Developers, in particular, like to point things at their random
kernel trees. In general though, relying on a full kernel source
tree being available isn't a good idea. Kernel headers change
dramatically across versions too so it's very likely that we would
need to have
Stefan Weil wrote:
Anthony Liguori schrieb:
For Debian systems, those headers are installed by package linux-libc-dev.
There are also packages for cross compilation in emdebian
(linux-libc-dev-mips-cross, linux-libc-dev-powerpc-cross, ...).
Yes, those headers did not always match the featur
> I think we need to use the output of 'make headers-install', which
> removes things like __user and CONFIG_*.
Yes. Assuming we do decide to import a set of headers, they should definitely
be the sanitised version created by make headers-install.
Paul
--
To unsubscribe from this list: send the
On Mon, May 04, 2009 at 08:51:21AM +0200, Stefan Weil wrote:
> Anthony Liguori schrieb:
> > Sorry this explanation is long winded, but this is a messy situation.
> >
> > In Linux, there isn't a very consistent policy about userspace kernel
> > header inclusion. On a typical Linux system, you're li
Anthony Liguori wrote:
Sorry this explanation is long winded, but this is a messy situation.
In Linux, there isn't a very consistent policy about userspace kernel
header inclusion. On a typical Linux system, you're likely to find
kernel headers in three places.
glibc headers (/usr/include/{
Anthony Liguori schrieb:
> Sorry this explanation is long winded, but this is a messy situation.
>
> In Linux, there isn't a very consistent policy about userspace kernel
> header inclusion. On a typical Linux system, you're likely to find
> kernel headers in three places.
>
> glibc headers (/usr/
12 matches
Mail list logo
