[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 5/6] hw/input/stellaris_input: Convert to qdev
|
From: |
Peter Maydell |
|
Subject: |
Re: [PATCH v2 5/6] hw/input/stellaris_input: Convert to qdev |
|
Date: |
Tue, 31 Oct 2023 15:36:54 +0000 |
On Tue, 31 Oct 2023 at 14:55, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> On 31/10/23 15:05, Peter Maydell wrote:
> > On Tue, 31 Oct 2023 at 13:55, Peter Maydell <peter.maydell@linaro.org>
> > wrote:
> >>
> >> On Mon, 30 Oct 2023 at 20:38, Mark Cave-Ayland
> >> <mark.cave-ayland@ilande.co.uk> wrote:
> >>>
> >>> On 30/10/2023 11:48, Peter Maydell wrote:
> >>> Is it worth converting this to use DEFINE_TYPES() during the conversion?
> >>> I know Phil
> >>> has considered some automation to remove the type_init() boilerplate for
> >>> the majority
> >>> of cases.
> >>
> >> I could, I guess. It seems a bit awkward that DEFINE_TYPES()
> >> wants you to pass it an array even when you only have one type,
> >> though, which is going to be a very common use case.
>
> For single type, there is no point beside enforcing a QOM style.
>
> I'll update docs/devel/qom.rst...
I do like that the macro means you're not writing an actual
function for the registration.
We could I guess have a DEFINE_TYPE() macro that was similar
to DEFINE_TYPES but emitted a function that called
type_register_static() instead of type_register_static_array().
Is that worth having? I'm not sure.
thanks
-- PMM
[PATCH v2 6/6] hw/input/stellaris_gamepad: Convert to qemu_input_handler_register(), Peter Maydell, 2023/10/30