From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z3wDs-0002aS-Au for Qemu-devel@nongnu.org; Sat, 13 Jun 2015 20:56:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z3wDp-0004n6-45 for Qemu-devel@nongnu.org; Sat, 13 Jun 2015 20:56:28 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z3wDo-0004mW-RK for Qemu-devel@nongnu.org; Sat, 13 Jun 2015 20:56:25 -0400 Received: by wiga1 with SMTP id a1so45449999wig.0 for ; Sat, 13 Jun 2015 17:56:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Liviu Ionescu In-Reply-To: Date: Sun, 14 Jun 2015 03:56:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B3F8291-A1F7-437C-8111-CC4800F200D4@livius.net> <42AEE112-EC4A-4814-B3C7-56EF1EF41363@livius.net> Subject: Re: [Qemu-devel] [RFC] QOM design - add instance data to Object (-> add constructors) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: QEMU Developers > On 14 Jun 2015, at 01:46, Peter Crosthwaite = wrote: >=20 >> 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. >>=20 >=20 > 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. the cortexm-mcu reference to machine is actually not a reference to the = container. as it is now, qemu packs some command line args into the = machine structure, and these values are needed during the MCU = construction. I don't know why they are packed inside the machine structure, probably = this is another unfortunate decision, but currently there is no other = way to get these values inside the cortexm-mcu object. >> GenericGPIOLEDInfo h103_machine_green_led =3D { >> .desc =3D "STM32-H103 Green LED, GPIOC[12], active low", >> .port_index =3D STM32_GPIO_PORT_C, >> .port_bit =3D 12, >> .active_low =3D true, >> .on_message =3D "[Green LED On]\n", >> .off_message =3D "[Green LED Off]\n", >> .use_stderr =3D true }; >=20 > Is any of this information needed for construction of can these fields > just be qdev properties? yes, the port index and bit. >=20 >>=20 >> static void stm32_h103_board_init_callback(MachineState *machine) >> { >> cortexm_board_greeting(machine); >> DeviceState *mcu =3D qdev_alloc(NULL, TYPE_STM32F103RB); >> { >> STM32F103RB_GET_CLASS(mcu)->construct(OBJECT(mcu), machine); >>=20 >> /* Set the board specific oscillator frequencies. */ >> DeviceState *rcc =3D stm32_mcu_get_rcc_dev(mcu); >=20 > You should try and avoid fishing sub-devices out of the container like > this if you can. >=20 >> qdev_prop_set_uint32(rcc, "hse-freq-hz", 8000000); /* 8.0 MHz = */ >> qdev_prop_set_uint32(rcc, "lse-freq-hz", 32768); /* 32 KHz */ >=20 > If these are crystal frequencies, then they should be properties of > the MCU object itself. these are properties specific to some of the STM32 MCUs, other families = have different properties. they are definitely not properties of the generic cortexm-mcu object. > 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. >>=20 >> the one-instance-per-class might be true for MCUs, but generally it = isn't, for example the LED object, you can have several LEDs in a = machine, all having a common class, but different instances. similarly = for GPIOs. >>=20 >=20 > But there doesn't seem to be any demand for construction-sensitive > info there - at least yet. I'm not sure it is so. a led requires a port bit to work. it can be constructed by first = constructing an object that encapsulates the port & bit, later passed to = the led, or, as it is now, the top led objects calls a virtual in the = child (stm32-led) to return the specific port & bit, and then connects = the interrupts. the second solution is easier to use. >> ah, just for having the information available for verbosity. here is = a typical run for a simple blinky application: >>=20 >=20 > can you use object_get_typename? the message is printed in the cortexm-mcu object, if at this level = object_get_typename() returns the child name and not the current object = name, then the answer is 'yes'. --- what you basically try to say is that all objects should be created at = .instance_init, using static recipes, always the same, all other = configuration should be done by setting properties, and there should be = no references from one object to another. well, I think this is simply not realistic. and the result of this = approach is that all objects will be actually constructed at realize(), = which is exactly what I tried to avoid. how do you suggest to efficiently implement dependencies between = peripherals? for example in stm32 the RCC includes clock enable bits for = all peripherals, including gpios. the current implementation uses a = pointer to the stm32-rcc object from each of the stm32-gpio objects. how = would you do it without this pointer? using listeners and notifiers to = inform each gpio when rcc bits are changed? how would the gpio register = to the notifier without a pointer to it? by name? how do you suggest the objects in a hierarchy communicate to each other = without constructors and virtuals? for example the STM32 capabilities = are known in the STM32F103RB object (let's say form the class data, so = available at .instance_init), but these capabilities are needed in the = stm32-mcu parent object, which will create the actual objects.=20 my feeling is that we have a communication problem and I'm not able to = explain you the exact problems that I'm facing.=20 perhaps a skype call, using screen sharing, would be more efficient to = clarify these issues. would you be available for such a call? (my skype = id is 'ilg-ul', you can call me at any time). regards, Liviu