[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 7/8] machine: query dump-guest-core machine prop

From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH 7/8] machine: query dump-guest-core machine property rather than qemu opts
Date: Wed, 11 Mar 2015 15:04:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 03/11/2015 01:06 PM, Andreas Färber wrote:
Am 11.03.2015 um 09:56 schrieb Michael S. Tsirkin:
On Tue, Mar 10, 2015 at 10:36:56PM +0100, Andreas Färber wrote:
Am 10.03.2015 um 22:24 schrieb Michael S. Tsirkin:
On Tue, Mar 10, 2015 at 06:50:24PM +0100, Andreas Färber wrote:

Am 04.02.2015 um 16:43 schrieb Marcel Apfelbaum:
Fixes a QEMU crash when passing dump_guest_core parameter in command line.

Explain that, please?

Pls note the submission date.  It's 1 month late to ask for
basic clarifications.

I've merged the patches, I'll fix up issues such as prettifying
includes by adding patches on top.

No, since the patch is not in qemu.git (it builds!) it is not too late
to fix it, nor too late to ask why a patch that introduces a breakage
does what it does.

I tried to say that I'm not holding this patch set up
because there are some basic questions. Paolo reviewed
it and gave an ack. If others want to re-start review 1 month
afterwards, that's fine, but I don't want to defer pull
request with this any longer. If someone can quickly spot
a serious non-cosmetic problem there, that's another
matter, and would make me defer the pull request.

(Moving the info from the cover letter into the
commit message would've been a good idea, Marcel.)

I can tweak commit messages, sure, since that does not require
re-testing it all.

All QEMU patches are supposed to be bisectable. It's our job as
maintainers to build-test each. If you do that 1 month later, that's not
my fault.


I have this patch in my tree and there's
no bisect issue, just test-built before and after this patch.
That's because I had the ifdefs in boards.h which you and
Peter objected to, but that is about cosmetics, I fixed that
with a patch on top to hopefully make you both happy.

All I was asking for is, please squash the patch(es) that fix(es) the
build issue. In particular if you applied the patch just yesterday when
we complained. We've been required to, so I expect the same rules to
apply to everyone.

In order to propose a better fix I tried to understand what the patch is
fixing, that's all. If an improvement of the commit message comes out of
that, good, but that was not the main purpose.


P.S. I was sick most of February and my Chromebook has a broken DRM
driver, not allowing for much bedside-hacking. ;)
Hi Andreas,
I hope you are feeling better now!

The main issue I see here (and believe me is not the reviews, they are always 
is that more than a month ago several developers complained about these crashes.
I stopped what I was doing and posted a series ASAP that was almost immediately
reviewed by Paolo.

I pinged twice already and nobody did anything about it.
Michael took it because nobody else did and now we have a situation:
"No good deed goes unpunished"

Now, we need a way to not let this happen.
I am afraid that next time I will not get lucky and nobody will take the 
patches :(.


Don't take my word for it, you can check out my tree and verify,
that would be very wellcome.

SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

reply via email to

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