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. Kevin
