From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZmBc-0005Fn-4m for qemu-devel@nongnu.org; Thu, 23 Jun 2011 11:51:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZmBa-0002hB-58 for qemu-devel@nongnu.org; Thu, 23 Jun 2011 11:51:19 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:48837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZmBZ-0002gy-P6 for qemu-devel@nongnu.org; Thu, 23 Jun 2011 11:51:18 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5NFcIQ1018753 for ; Thu, 23 Jun 2011 09:38:18 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5NFp0BI172162 for ; Thu, 23 Jun 2011 09:51:00 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5NFoxUP028155 for ; Thu, 23 Jun 2011 09:50:59 -0600 Message-ID: <4E0360CC.7050001@linux.vnet.ibm.com> Date: Thu, 23 Jun 2011 10:50:36 -0500 From: Michael Roth 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> <4E035722.3040203@redhat.com> In-Reply-To: <4E035722.3040203@redhat.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: Avi Kivity 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 10:09 AM, Avi Kivity wrote: > 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). > Yup, and their userspace stuff has some pretty complex library dependencies (pthreads, X11) that work well-enough for most. I'm sure we'll run into some issues, but if we limit ourselves to stable interfaces where possible they should be minimal, and if need be we can ship different binaries for certain arch/distro combos (though that can get out of hand fairly quickly and should be avoided) >> 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. > I mean mostly just to avoid having different guest tools in the ISO that were all built in different environments, since that might exacerbate library mismatches.