qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 00/19] hw: Set QDev properties using QDev API (part 1/3)


From: BALATON Zoltan
Subject: Re: [PATCH 00/19] hw: Set QDev properties using QDev API (part 1/3)
Date: Fri, 3 Feb 2023 19:52:48 +0100 (CET)

On Fri, 3 Feb 2023, Philippe Mathieu-Daudé wrote:
On 3/2/23 19:08, Philippe Mathieu-Daudé wrote:
QEMU provides the QOM API for core objects.
Devices are modelled on top of QOM as QDev objects.

There is no point in using the lower level QOM API with
QDev; it makes the code more complex and harder to review.

I first converted all the calls using errp=&error_abort or
&errp=NULL, then noticed the other uses weren't really
consistent.

A QDev property defined with the DEFINE_PROP_xxx() macros
is always available, thus can't fail. When using hot-plug
devices, we only need to check for optional properties
registered at runtime with the object_property_add_XXX()
API. Some are even always registered in device instance_init.

I have probably been overzealous, so I tagged the patches
not using errp=&error_abort|&error_fatal|NULL as RFC.

PPC and ARM conversions will follow as two different series.

  46 files changed, 155 insertions(+), 221 deletions(-)

Forgot to mention, this is based on
20230203163021.35754-1-philmd@linaro.org/">https://lore.kernel.org/qemu-devel/20230203163021.35754-1-philmd@linaro.org/
"hw/acpi/cpu_hotplug: Convert 'Object *device' -> 'DeviceState *parent'"

Based-on: <20230203163021.35754-1-philmd@linaro.org>

Doing these clean ups is nice but making tree wide one line changes in the middle of development window has a high chance of breaking series not yet merged which is less nice. I'm worried because it's hard enough to get a series reviewed and catch the attention of the maintainer so that it will also be merged. But when another series that causes my series to not apply lands first mine will get rejected needing a rebase and I have to start again which might mean it will miss the freeze and get forgotten or delayed until the next release. This is OK as long as the other conflicting series is adding functionality or fixing bugs but if it's just trivial clean up then maybe it would be better to merge these tree wide clean ups during the soft freeze or first after opening development to reduce the number of comflicts. It would also be less of a problem if merging a series would not take more than half of the development window but would land within a week or so but maintainers are often too busy to handle their job so we're limited to one ot two pulls per release. Please consider this when submitting these clean up series.

Regards,
BALATON Zoltan

reply via email to

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