Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
>> 
>>> We also need to upload the ia64 firmware for kvm, and make it
>>> available for users use. At least, we need to provide the binary.
>>> 
>> 
>> beware that actually providing the binary without sources might be a
>> problem for some distributions (like debian and derivatives like
>> ubuntu). 
>> 
>> most likely getting the sources and a makefile which could be used
>> to build the binary and copy it to the qemu/pc-bios/ directory, at
>> release time or when the sources had been changed and it needs to be
>> rebuilt, and for convenience so it can be distributed with the
>> release tar.gz will be preferred. 
>> 
>> for hints on how to get that look at the Makefiles in the bios or
>> vgabios top level directories and the top level Makefile
>> 
>> 
> 
> Note that we ship x86 binaries for two reasons:
> - qemu does it that way, and we inherited it, before the need arose to
> make modifications
> - obscure tools are needed to build the binaries (iasl and dev86)
> 
> Since ia64 doesn't have these issues (is that right?) then we can
> probably do a source-only release.

Ia64 firmware build need edk tools(very big package), and very hard to
setup the environment correclty.  And it is not friendly to users :(
Maybe binary is also needed. 
Xiantao


>>> BTW, current ia64 binary has 2M size, is it OK to upload it to
>>> kvm-source tree ? 
>>> 
>> 
>> if you are talking about the binary only, EFI BIOS from Intel, then
>> it could be problematic (because of the free software guidelines of
>> some distributions) and of course will need to have also some sort
>> of README file clearly specifying that the license allows for
>> re-distribution and can be used at least together with kvm (like the
>> ELPIN vga bios was licensed for BOCHS) 
>> 
>> IMHO is probably better to use only the GPL version with sources and
>> distribute that with kvm source packages and let the users or
>> distributions 
>> to manage the distribution/installation of BLOBs otherwise as that
>> keeps the lawyers from distracting us from the interesting technical
>> issues. 
>> 
> 
> I agree, let's avoid binary-only components if possible.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to