[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 03/20] piix4: Add a i8259 Interrupt Controller as specified in datasheet



El mar, 22-10-2019 a las 10:42 +0100, Peter Maydell escribió:
> On Tue, 22 Oct 2019 at 09:52, Esteban Bosse <estebanbosse@xxxxxxxxx>
> wrote:
> > El vie, 18-10-2019 a las 15:47 +0200, Philippe Mathieu-Daudé
> > escribió:
> > > +static void piix4_request_i8259_irq(void *opaque, int irq, int
> > > level)
> > > +{
> > > +    PIIX4State *s = opaque;
> > > +    qemu_set_irq(s->cpu_intr, level);
> > > +}
> > I would like to understand why in `PIIX4State *s = opaque;` its not
> > necessary a cast or a object macro magic.
> > Something like:
> > PIIX4State *s = (PIIX4State*)opaque;
> > PIIX4State *s = PIIX4STATE(opaque);
> 
> The simple answer to "why don't we need a cast" is
> "because the type of 'opaque' is 'void *', and in C there is
> no need to explicitly cast a 'void *' as it will be implicitly
> converted to the pointer type of the destination". (This is
> different from C++, which does require an explicit cast for void*.)
> 
> For QOM types, QEMU conventionally uses the QOM casting
> macro to convert a pointer-to-instance to
> pointer-to-instance-of-parent-class and vice versa.
> In some places, like this one, what we have is just a
> void* representing opaque data having been passed around.
> You could use the QOM cast macro here, which would add
> a bit of extra type-safety, but the project doesn't have
> a strong convention here on whether to do so or not, so
> you'll often see the just-assignment code.
> 
> thanks
> -- PMM

Thank you very much for your detailed explanation :).


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.