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

[Michael Roth <mdroth@linux.vnet.ibm.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<alevy@redhat.com> 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.