qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: Qemu Guest Tools ISO


From: Michael Roth
Subject: Re: [Qemu-devel] RFC: Qemu Guest Tools ISO
Date: Thu, 23 Jun 2011 10:50:36 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11

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<address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]