qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props
Date: Tue, 07 Jan 2014 13:33:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Am 16.12.2013 10:33, schrieb Peter Maydell:
> Anyway, I don't actively object to this series. I just think
> Anthony's going in the wrong direction which is why I haven't
> been particularly eager to actively mark it as reviewed-by me
> either...

Sorry for not taking the time to reply to these concerns earlier. I
thought it was self-speaking that the enterprise Linux distributors
among us want a safeguard to avoid customers from crashing a
long-running VM with some avoidable device_add.

I can't say that I am thrilled about the lengthy name, but this
refactoring has raised awareness of what no_user is supposed to be used
for and where not. As a reminder, Anthony didn't want the direct patch
to simply honor no_user in device_add again, an apparent regression, and
this appears to address his request to Markus' and my understanding.

We can still rename the field again, split or complement its use,
refactor devices and, e.g., CPU/SysBus/timer device infrastructure, etc.
all as follow-ups.

I might have a bad reputation of being strict in my patch review, but
requiring a patch to be the ultimate, final-set-in-stone solution has
not been one of them, if it does not affect users. :) Apart from the
intended regression fix, the choices discussed affect developers only.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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