qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0


From: Anthony Liguori
Subject: Re: [Qemu-devel] insmod virtio-blk is broken in qemu 1.0
Date: Mon, 19 Dec 2011 13:44:33 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 12/19/2011 01:40 PM, Richard W.M. Jones wrote:
On Mon, Dec 19, 2011 at 07:16:02PM +0000, Daniel P. Berrange wrote:
On Mon, Dec 19, 2011 at 07:04:54PM +0000, Richard W.M. Jones wrote:
On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote:
I would like to point out that August ->  October is a pretty long
time period for a regression like this to exist.  I think that
really indicates that the primary problem is testing, not frequency
of SeaBIOS updates.

Fair point.

My understanding is we're going to switch to having qemu.git in Fedora
Rawhide, which means that libguestfs will always be testing the
'perfect storm' of qemu + kernel + glibc from git (once glibc get
their act together anyhow, just qemu + kernel at first).

We usually do a build and a comprehensive test at least once a week,
often a few times a week, so we would have picked this up much sooner.

That wouldn't actually catch this problem, because when we build
QEMU in Fedora, we never use the SeaBIOS that QEMU includes in
GIT. Fedora always ships the newest SeaBIOS release available
from upstream, regardless of what QEMU includes.

Ah yes indeed, I forgot about this.

Nevertheless, it'll at least improve other aspects of our
qemu testing :-)

In reply to Anthony: the reason Fedora does this is because
binary blobs aren't permitted, no matter what the origin.  We
have to build SeaBIOS from source, and the choice is made to
build from the upstream SeaBIOS source, not from the source
release indirectly pointed to by qemu.

FWIW, we ship SeaBIOS source directly in our release tarballs. There's nothing indirect about it.

Fedora could have a seabios-qemu RPM that was built from the qemu SRPM. Since it ultimately is going to live in /usr/share/qemu, that seems like a nicer thing to do AFAICT.

You could have an alternatives mechanism if people really wanted to use upstream SeaBIOS...

Regards,

Anthony Liguori


Rich.





reply via email to

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