qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
To: Liviu Ionescu <ilg@livius.net>
Cc: QEMU Developers <Qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC] QOM design - add instance data to Object (-> add constructors)
Date: Sat, 13 Jun 2015 15:46:13 -0700	[thread overview]
Message-ID: <CAEgOgz4eMbxVGd0duAEKg-TRYdvqJbyFwV9osqaZzR10pBi90A@mail.gmail.com> (raw)
In-Reply-To: <DF196869-BFFC-4FB2-A2DB-CA1ED64367DB@livius.net>

On Sat, Jun 13, 2015 at 12:52 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 13 Jun 2015, at 21:57, Liviu Ionescu <ilg@livius.net> wrote:
>>
>> ... so, no, the class structure is not suitable for multi-instances objects, and even for singletons I think that using it for passing such configuration data is generally abusive.
>
> not to mention that in real life situations, constructors are used to pass non-static data, for example the 'machine' structure (for various command line params) when constructing MCUs, or the 'mcu' when constructing LEDs.
>

I think these are both questionable examples, as they are contained
objects taking and relying on pointers to their container which
reduces their re-usability as a modular component.

> passing these pointers orderly to the entire hierarchy is very simple when using standard constructors.
>
> how would you pass them with the existing .instance_init or .instance_post_init support? I don't think it is possible, which means the entire object construction needs to be delegated to realize(), which is way too late.
>
>
> for a better understanding of the problem, I'm copying again the same (fully functional) code to create boards:
>
> /* ----- Olimex STM32-H103 ----- */
>
> GenericGPIOLEDInfo h103_machine_green_led = {
>     .desc = "STM32-H103 Green LED, GPIOC[12], active low",
>     .port_index = STM32_GPIO_PORT_C,
>     .port_bit = 12,
>     .active_low = true,
>     .on_message = "[Green LED On]\n",
>     .off_message = "[Green LED Off]\n",
>     .use_stderr = true };

Is any of this information needed for construction of can these fields
just be qdev properties?

>
> static void stm32_h103_board_init_callback(MachineState *machine)
> {
>     cortexm_board_greeting(machine);
>     DeviceState *mcu = qdev_alloc(NULL, TYPE_STM32F103RB);
>     {
>         STM32F103RB_GET_CLASS(mcu)->construct(OBJECT(mcu), machine);
>
>         /* Set the board specific oscillator frequencies. */
>         DeviceState *rcc = stm32_mcu_get_rcc_dev(mcu);

You should try and avoid fishing sub-devices out of the container like
this if you can.

>         qdev_prop_set_uint32(rcc, "hse-freq-hz", 8000000); /* 8.0 MHz */
>         qdev_prop_set_uint32(rcc, "lse-freq-hz", 32768); /* 32 KHz */

If these are crystal frequencies, then they should be properties of
the MCU object itself. The MCU property setter then delegates its
property to the sub-device. This abstracts SoC internals away from the
board layer. Alias properties can make shorter work of this.

Regards,
Peter

>     }
>     qdev_realize(mcu);
>
>     /* Board peripheral objects */
>     DeviceState *led = qdev_alloc(NULL, TYPE_STM32_GPIO_LED);
>     {
>         STM32_GPIO_LED_GET_CLASS(led)->construct(OBJECT(led),
>                 &h103_machine_green_led, mcu);
>     }
>     qdev_realize(led);
> }
>
> static QEMUMachine stm32_h103_machine = {
>     .name = "STM32-H103",
>     .desc = "Olimex Header Board for STM32F103RBT6 (Experimental)",
>     .init = stm32_h103_board_init_callback };
>
> -----------------------------------------------
>
> regards,
>
> Liviu
>
>

  reply	other threads:[~2015-06-13 22:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12 11:33 [Qemu-devel] [RFC] QOM design - add instance data to Object Liviu Ionescu
2015-06-13  8:42 ` Liviu Ionescu
2015-06-13  9:29 ` Peter Crosthwaite
2015-06-13 11:41   ` Liviu Ionescu
2015-06-13 17:53     ` [Qemu-devel] [RFC] QOM design - add instance data to Object (-> add constructors) Liviu Ionescu
2015-06-13 18:29     ` [Qemu-devel] [RFC] QOM design - add instance data to Object Peter Crosthwaite
2015-06-13 18:57       ` Liviu Ionescu
2015-06-13 19:52         ` [Qemu-devel] [RFC] QOM design - add instance data to Object (-> add constructors) Liviu Ionescu
2015-06-13 22:46           ` Peter Crosthwaite [this message]
2015-06-14  0:56             ` Liviu Ionescu
2015-06-14  1:49               ` Peter Crosthwaite
2015-06-14 12:43                 ` Liviu Ionescu
2015-06-14 13:39                   ` Liviu Ionescu
2015-06-15  7:35                   ` Liviu Ionescu
2015-06-14 14:21                 ` Liviu Ionescu
2015-06-13 22:48         ` [Qemu-devel] [RFC] QOM design - add instance data to Object Peter Crosthwaite
2015-06-14 18:47   ` Liviu Ionescu
2015-06-14 21:28     ` Peter Crosthwaite

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=CAEgOgz4eMbxVGd0duAEKg-TRYdvqJbyFwV9osqaZzR10pBi90A@mail.gmail.com \
    --to=peter.crosthwaite@xilinx.com \
    --cc=Qemu-devel@nongnu.org \
    --cc=ilg@livius.net \
    /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).