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

[Jan Kiszka]

On 2012-01-31 17:49, Anthony Liguori wrote:
> On 01/31/2012 10:42 AM, Jan Kiszka wrote:
>> 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?
> 
> Already does that.  You'll get a run time warning.

Fine.

> 
>> I'm not worried about
>> lacking compile-time checks if we keep them for runtime.
> 
> I'm worried about:
> 
> object_property_set_link(obj, "pci", OBJECT(&s->pic));
> 
> vs:
> 
> spk->pic = s->pic;
> 
> Or:
> 
> pcspk_set_pic(spk, &s->pic);
> 
> I tend to make a lot of typos, I like the compiler to catch them for me at 
> build 
> time.

Well, but this enforces clean interfaces - just postpones the check.
Nothing can be set in the foreign device state outside its core.

Jan

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