Re: [Qemu-devel] [RFC] QOM design - add instance data to Object (-> add constructors)

[Liviu Ionescu]

> On 14 Jun 2015, at 01:46, Peter Crosthwaite <address@hidden> wrote:
> 
>> 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.

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 = {
>>    .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?

yes, the port index and bit.

> 
>> 
>> 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.

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.

>> 
>> 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.
>> 
> 
> 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:
>> 
> 
> 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. 


my feeling is that we have a communication problem and I'm not able to explain 
you the exact problems that I'm facing. 

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