From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0y08-00083t-Sh for qemu-devel@nongnu.org; Mon, 04 May 2009 09:14:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0y03-00080U-S1 for qemu-devel@nongnu.org; Mon, 04 May 2009 09:14:32 -0400 Received: from [199.232.76.173] (port=38216 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0y03-00080O-N0 for qemu-devel@nongnu.org; Mon, 04 May 2009 09:14:27 -0400 Received: from mail-gx0-f176.google.com ([209.85.217.176]:55436) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0y03-0003Zk-GE for qemu-devel@nongnu.org; Mon, 04 May 2009 09:14:27 -0400 Received: by gxk24 with SMTP id 24so8027777gxk.10 for ; Mon, 04 May 2009 06:14:27 -0700 (PDT) Message-ID: <49FEEA31.20409@codemonkey.ws> Date: Mon, 04 May 2009 08:14:25 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU References: <49FE0E97.30602@codemonkey.ws> <49FE9ED0.7060301@redhat.com> In-Reply-To: <49FE9ED0.7060301@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "qemu-devel@nongnu.org" , kvm-devel 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 a lot of #ifdefs dependent on kernel versions, or some >> of the uglier work arounds we have in usb-linux.c. >> >> I think the best way to avoid #ifdefs and dependencies on >> broken/incomplete glibc headers is to include all of the Linux >> headers we need within QEMU. The attached patch does just this. >> >> I think there's room for discussion about whether we really want to >> do this. We could potentially depend on some more common glibc >> headers (like asm/types.h) while bringing in less reliable headers >> (if_tun.h/virtio*). Including them all seems like the most robust >> solution to me though. >> >> Comments? > > I think we need to use the output of 'make headers-install', which > removes things like __user and CONFIG_*. I was thinking about that as a possibility too. We still need the same basic infrastructure though. Regards, Anthony Liguori