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

[Anthony Liguori]

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.

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

Regards,

Anthony Liguori

> Jan