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

[Natalia Portillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ok you're forgetting one thing:

90% of the devices we emulate are real physical ones.
The drivers for those devices in non-opensource guests already exist, and most 
of the times prevent we distributing them (read the EULA).

I think a "guest tools" with binary drivers for binary platforms (Windows, 
OS/2, NeXT, DOS) is a good idea.
One with binary drivers for open-source platforms (Linux, *BSD) is really 
stupid, will create hundreds of conflicts.
One with source drivers for open-source platforms is reinventing the wheel. The 
distros and systems already take care about drivers, including even drivers for 
other VMs.

So for any kind of usefulness we need to ask Creative Labs, Intel, AMD, VMWare, 
Realtek, so on, permissions to distribute their drivers.
I'm not sure they will allow us (pretty sure the VMWare video one will not be 
allowed ever).

In the case they allow us and create the guest tools disc, we can create a 
false device that a dormant process (TSR in DOS world) hears off.
That's what VMWare does, writes in that device requesting guest tools version 
(if none installed, noone answers), and if the provided one is better informs 
the user and offers to automount it.

Regards

El 23/06/2011, a las 16:52, Avi Kivity escribió:

> On 06/23/2011 06:25 PM, Anthony Liguori wrote:
>>> 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.
>> 
>> 
>> Good libraries provide strong ABI compatibility.
>> 
>> Something like glib clearly documents what version of the library functions 
>> are available in, if you still to responsibly common functions, ABI 
>> compatibility should be much of an issue.
> 
> I don't know about glib, but glibc only guarantees backward compatibility, 
> not forward compatibility.  If you build against a newer glibc, your 
> executable may not run with an older glibc, even if the symbols exist in both.
> 
> See [1] which touches on the issue; I don't have a better reference.
> 
> [1] ftp://ftp.kernel.org/pub/software/libs/glibc/hjl/compat/index.html
> 
> -- 
> error compiling committee.c: too many arguments to function
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iF4EAREIAAYFAk4HzaQACgkQv/wfOsykIRTVoQD/SgniEhqOCIf5FIiBz7RT0GAc
g8aA4FGWdKQB6jrfbwwA/igtLCAjhCpF/lFJ6o+0dUU2r3tT+gvDdZeURG82Xr5Z
=2Z/r
-----END PGP SIGNATURE-----