[Top][All Lists]

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

Re: [Qemu-devel] [PATCH stable-1.1 00/26] Initial tree and candidates fo

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH stable-1.1 00/26] Initial tree and candidates for stable-1.1
Date: Mon, 25 Jun 2012 17:14:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Am 25.06.2012 16:14, schrieb Michael Roth:
> On Mon, Jun 25, 2012 at 02:58:40PM +0200, Kevin Wolf wrote:
>> Am 23.06.2012 02:33, schrieb Michael Roth:
>>> Hi everyone,
>>> I've set up a tree for stable-1.1 at:
>>> git://github.com/mdroth/qemu.git stable-1.1
>>> That is simply the initial commit for v1.1.0
>>> I've set up a staging tree for the first batch of commits at:
>>> git://github.com/mdroth/qemu.git stable-1.1-staging
>>> This should capture everything explicitly tagged for stable/1.1. I've also
>>> pulled in relevant build fixes and a handful of applicable bug fixes.
>>> Please let me know if I've missed any patches, or if any of these shouldn't 
>>> be
>>> applied.
>>> Testing so far has been all-target builds on x86, make check, qemu-test, and
>>> installation + old(current stable-1.1)->new and new->old migration for
>>> fc15/fc16/winxp. I plan on doing a more extensive final round of testing 
>>> later
>>> next week before committing, as that will more or less be QEMU v1.1.1
>>> For the next release I plan on doing weekly or bi-weekly testing of staged
>>> patches and emails of this sort before committing to stable-1.1, depending 
>>> on
>>> the number of patches and code churn, and will continue working off my
>>> stable-1.1-staging tree on github for those.
>> Please consider as well:
>> 4bb9c939a57103898f5a51aa6a7336eb3320d923 ahci: SATA FIS is 20 bytes...
> I originally had this in the queue but it looks like the only effect is
> to avoid allocating/initializing an extra 16 bytes on the stack. I
> didn't see any other potential side-effects so decided to drop it. Let
> me know if I'm missing something though.

When I reviewed it, I didn't fully understand if it really matters, but
it does corrupt some other state. It's possible that the overwritten
data isn't used anyway before it's recreated, but as I wasn't sure, I
thought backporting an easy fix wouldn't hurt.


reply via email to

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