qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Bernhard Beschow <shentey@gmail.com>
Cc: "Hervé Poussineau" <hpoussin@reactos.org>,
	qemu-devel@nongnu.org, "Aurelien Jarno" <aurelien@aurel32.net>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH 1/2] isa/piix4: Resolve RTCState attribute
Date: Sat, 5 Feb 2022 18:53:38 +0000	[thread overview]
Message-ID: <CAFEAcA_y69=iXMH75dHeNkxMa038Z7Xk63GW9fdcAFHJSWS=sA@mail.gmail.com> (raw)
In-Reply-To: <20220205175913.31738-2-shentey@gmail.com>

On Sat, 5 Feb 2022 at 18:05, Bernhard Beschow <shentey@gmail.com> wrote:
>
> Assuming that mc146818_rtc_init() is "syntactic sugar" for code that could
> be converted into configuration in the future, this patch is a step towards
> this future by freeing piix4 to care about the inner details of mc146818.
>
> Furthermore, by reusing mc146818_rtc_init(), piix4's code becomes more
> homogenious to other code using the mc146818. So piix4 can be refactored in
> the same way as code already using mc146818_rtc_init().
>
> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> ---
>  hw/isa/piix4.c | 15 +--------------
>  1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 0fe7b69bc4..08b4262467 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -46,7 +46,6 @@ struct PIIX4State {
>      qemu_irq cpu_intr;
>      qemu_irq *isa;
>
> -    RTCState rtc;
>      /* Reset Control Register */
>      MemoryRegion rcr_mem;
>      uint8_t rcr;
> @@ -193,22 +192,11 @@ static void piix4_realize(PCIDevice *dev, Error **errp)
>      i8257_dma_init(isa_bus, 0);
>
>      /* RTC */
> -    qdev_prop_set_int32(DEVICE(&s->rtc), "base_year", 2000);
> -    if (!qdev_realize(DEVICE(&s->rtc), BUS(isa_bus), errp)) {
> -        return;
> -    }
> -    isa_init_irq(ISA_DEVICE(&s->rtc), &s->rtc.irq, RTC_ISA_IRQ);
> +    mc146818_rtc_init(isa_bus, 2000, NULL);
>
>      piix4_dev = dev;
>  }
>
> -static void piix4_init(Object *obj)
> -{
> -    PIIX4State *s = PIIX4_PCI_DEVICE(obj);
> -
> -    object_initialize(&s->rtc, sizeof(s->rtc), TYPE_MC146818_RTC);
> -}
> -
>  static void piix4_class_init(ObjectClass *klass, void *data)
>  {
>      DeviceClass *dc = DEVICE_CLASS(klass);
> @@ -233,7 +221,6 @@ static const TypeInfo piix4_info = {
>      .name          = TYPE_PIIX4_PCI_DEVICE,
>      .parent        = TYPE_PCI_DEVICE,
>      .instance_size = sizeof(PIIX4State),
> -    .instance_init = piix4_init,
>      .class_init    = piix4_class_init,
>      .interfaces = (InterfaceInfo[]) {
>          { INTERFACE_CONVENTIONAL_PCI_DEVICE },

This looks like it's going backwards from the way we'd usually
write code for devices that contain other devices these days.
The "we have an init function that does stuff" is the older
style. The newer style has the inner-device as an embedded
struct in the container-device struct, which is initialized,
configured and realized using standard functions like object_initialize
and qdev_realize. (I do wonder whether that ought to be
object_initialize_child() here, incidentally, but haven't checked the
details to be certain.)

The existing uses of mc146818_rtc_init() are mostly in older
code, and also in board-initialization code, which traditionally
didn't have a convenient struct to embed the device-struct into.
hw/isa/vt82c686.c is the only use in another device model
(which could in theory be refactored to the embed-the-device-struct
style, though the benefit of making the change isn't large, which
is one reason we still have the mix of both in the tree).

thanks
-- PMM


  reply	other threads:[~2022-02-05 19:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-05 17:59 [PATCH 0/2] Make mc146818rtc more self-contained Bernhard Beschow
2022-02-05 17:59 ` [PATCH 1/2] isa/piix4: Resolve RTCState attribute Bernhard Beschow
2022-02-05 18:53   ` Peter Maydell [this message]
2022-02-05 22:59     ` Philippe Mathieu-Daudé via
2022-02-05 17:59 ` [PATCH 2/2] mc146818rtc: Unexport RTCState Bernhard Beschow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFEAcA_y69=iXMH75dHeNkxMa038Z7Xk63GW9fdcAFHJSWS=sA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=aurelien@aurel32.net \
    --cc=f4bug@amsat.org \
    --cc=hpoussin@reactos.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shentey@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).