Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Stefan Weil
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

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Avi Kivity
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

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Edgar E. Iglesias
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 likely to

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Anthony Liguori
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

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Anthony Liguori
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

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Christoph Hellwig
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 depending

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Lennart Sorensen
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

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Edgar E. Iglesias
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 kernel to

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Anthony Liguori
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

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Avi Kivity
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

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU

2009-05-04 Thread Anthony Liguori
Avi Kivity wrote: random kernel tree 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