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

From: BALATON Zoltan <balaton@eik.bme.hu>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	 Markus Armbruster <armbru@redhat.com>,
	 Eduardo Habkost <eduardo@habkost.net>,
	qemu-riscv@nongnu.org
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)	[thread overview]
Message-ID: <fd0b660d-344f-fcce-f499-41a6d4317aee@eik.bme.hu> (raw)
In-Reply-To: <0fc499be-7981-6a6d-9115-3c6f320b0c04@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

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