[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-arm
Subject:    Re: [PATCH v2 5/6] hw/input/stellaris_input: Convert to qdev
From:       Peter Maydell <peter.maydell () linaro ! org>
Date:       2023-10-31 15:36:54
Message-ID: CAFEAcA9tipCFVfnR0Z9P8rvmtFdvzsn7dkz3FUAkTEuH+35d2g () mail ! gmail ! com
[Download RAW message or body]

On Tue, 31 Oct 2023 at 14:55, Philippe Mathieu-Daud=C3=A9 <philmd@linaro.or=
g> 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 conversi=
on? 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

[prev in list] [next in list] [prev in thread] [next in thread]