Re: [Qemu-devel] [PATCH 06/15] piix: create i8254 through composition

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-01-31 15:56, Anthony Liguori wrote:
> On 01/31/2012 08:51 AM, Jan Kiszka wrote:
>> On 2012-01-31 15:47, Anthony Liguori wrote:
>>> On 01/31/2012 08:34 AM, Jan Kiszka wrote:
>>>> On 2012-01-26 20:00, Anthony Liguori wrote:
>>>>> @@ -548,6 +550,13 @@ static int piix3_realize(PCIDevice *dev)
>>>>>        /* Setup the RTC IRQ */
>>>>>        s->rtc.irq = rtc_irq;
>>>>>
>>>>> +    /* Realize the PIT */
>>>>> +    qdev_set_parent_bus(DEVICE(&s->pit), BUS(s->bus));
>>>>> +    qdev_init_nofail(DEVICE(&s->pit));
>>>>> +
>>>>> +    /* FIXME this should be refactored */
>>>>> +    pcspk_init(ISA_DEVICE(&s->pit));
>>>>
>>>> Fixing ATM, ie. converting to qdev/QOM.
>>>>
>>>> Q: How do I use qdev_property_add_link&   Co. to establish the relation
>>>> from the speaker port device to the PIT?
>>>
>>> In the state structure, have:
>>>
>>> struct PCSpkState {
>>>       ...
>>>       PITState *pit;
>>> };
>>>
>>> In the pcspk instance_init, do:
>>>
>>> object_property_add_link(obj, "pit", TYPE_PIT, (Object **)&s->pit, NULL);
>>>
>>> In the pcspk realize function (DeviceClass::init), do:
>>>
>>> assert(s->pit != NULL); // make sure the pit link is set
>>>
>>> And that's it.
>>>
>>> You can set the s->pit field directly.  You are not required to use any special
>>> QOM function to interact with link properties.
>>>
>>> BTW, this is yet another benefit of making structures public.  You can take the
>>> address of a child and set link fields directly without accessors.
>>
>> Well, that has two sides. We introduced properties to avoid this direct
>> messing.
>>
>> Does linking also work without exposing internals?
> 
> Yes, you can set links through properties (although I haven't added those 
> accessors yet).
> 
> But...  you lose type safety because now you're dealing with strings.

I don't get yet why we have to give up on type safety here. Isn't all
information stored in the property entry? Can't some
object_set_property() service take the object pointer and validate its
type before writing at the target location? I'm not worried about
lacking compile-time checks if we keep them for runtime.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux