From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZlXA-0000hj-Fp for qemu-devel@nongnu.org; Thu, 23 Jun 2011 11:09:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZlX8-0003uR-R0 for qemu-devel@nongnu.org; Thu, 23 Jun 2011 11:09:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZlX8-0003uI-8a for qemu-devel@nongnu.org; Thu, 23 Jun 2011 11:09:30 -0400 Message-ID: <4E035722.3040203@redhat.com> Date: Thu, 23 Jun 2011 18:09:22 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E023A9D.9010205@linux.vnet.ibm.com> <20110623092954.GA2682@bow.redhat.com> <4E032AC5.2080709@redhat.com> <4E0353C3.60600@linux.vnet.ibm.com> In-Reply-To: <4E0353C3.60600@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: Qemu Guest Tools ISO List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: agl@linux.vnet.ibm.com, Stefan Hajnoczi , "qemu-devel@nongnu.org Developers" , Anthony Liguori , pmyers@redhat.com, bsarathy@redhat.com On 06/23/2011 05:54 PM, Michael Roth wrote: > On 06/23/2011 07:00 AM, Avi Kivity wrote: >> On 06/23/2011 02:08 PM, Stefan Hajnoczi wrote: >>> On Thu, Jun 23, 2011 at 10:29 AM, Alon Levy wrote: >>> > On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote: >>> >> Goal: >>> >> >>> >> Provide a mechanism, similar to vmware and virtualbox guest tools >>> >> ISOs, that allows us to easily distribute guest tools (and >>> >> potentially drivers) for linux and windows guests. >>> > >>> > What would be the advantage for linux guests, with their package >>> managers already >>> > handling this task? I see how it would make testing easier with >>> various linux >>> > distributions, but for management I wonder if it won't be easier to >>> use the >>> > package management system to update the guests same as the hosts. >>> >>> If the guest tools come from the host QEMU we don't need complicated >>> compatibility testing and fallbacks. Guest and host will be in sync >>> and support the same features. >>> >> >> Even building the tools would be very hard. In general if you build >> against libc version y, you cannot expect your code to work against libc >> version y-1, unless you take special measures. With other libraries the >> "special measures" may not even be possible. > > Nvidia/ATI driver installers might be a good (or bad) precedent, I > believe they ship a generic blob....need to confirm. The kernel keeps breaking it and they keep fixing it. They're solving a much more difficult problem though (an explicitly unstable API). > We'd want to have a controlled environment that's used for building > the tools we add to the ISO though. I'm not even sure that such a least-common-denominator exists. -- error compiling committee.c: too many arguments to function