On Mon, Dec 17, 2012 at 11:08:43PM +0100, Andreas Färber wrote:
> Am 17.12.2012 22:18, schrieb Michael S. Tsirkin:
> > On Mon, Dec 17, 2012 at 10:13:11PM +0100, Andreas Färber wrote:
> >> Am 17.12.2012 21:48, schrieb Michael S. Tsirkin:
> >>> On Mon, Dec 17, 2012 at 07:25:08PM +0100, Andreas Färber wrote:
> >>>> Am 17.12.2012 19:21, schrieb Paolo Bonzini:
> >>>>> Il 17/12/2012 18:55, Andreas Färber ha scritto:
> >>>>>> Am 17.12.2012 16:45, schrieb Michael S. Tsirkin:
> >>>>>>> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> >>>>>>> index 3ea4140..63ae888 100644
> >>>>>>> --- a/hw/virtio-pci.c
> >>>>>>> +++ b/hw/virtio-pci.c
> >>>>>>> @@ -98,34 +98,34 @@ bool virtio_is_big_endian(void);
> >>>>>>>
> >>>>>>> /* virtio device */
> >>>>>>>
> >>>>>>> -static void virtio_pci_notify(void *opaque, uint16_t vector)
> >>>>>>> +static void virtio_pci_notify(DeviceState *d, uint16_t vector)
> >>>>>>> {
> >>>>>>> - VirtIOPCIProxy *proxy = opaque;
> >>>>>>> + VirtIOPCIProxy *proxy = container_of(d, VirtIOPCIProxy,
> >>>>>>> pci_dev.qdev);
> >>>>>>
> >>>>>> Nack. This is going the wrong direction QOM-wise and you among all
> >>>>>> others know that from PCI host bridges!
> >>>>>
> >>>>> Well, that's just a difference of VIRTIO_PCI_PROXY(d) vs. container_of.
> >>>>
> >>>> VIRTIO_PCI_PROXY(d) would be acceptable, sure. But as-is this patch just
> >>>> pushes unnecessary work on Fred, me, you or anyone else who works with
> >>>> QOM.
> >>>
> >>> What's VIRTIO_PCI_PROXY? Note this is data path we do not want extra
> >>> code.
> >>
> >> My complaint is the direct access of pci_dev, qdev, etc. parent fields
> >> in many places as the main change of this patch. Those mean more places
> >> to touch in a future patch.
> >>
> >> Use of any new-style macro hiding these - wherever the particular one
> >> suggested may be defined or whether it needs to be added - is better.
> >>
> >> If performance of dynamic_cast is an issue - something I'd leave you to
> >> discuss with Anthony - you can just do a C cast directly. Just don't
> >> spread this qdev paradigm further please.
> >
> > OK so just
> >
> > #define VIRTIO_PCI_PROXY(d) container_of(d, VirtIOPCIProxy, pci_dev.qdev)
> >
> > is OK with you?
>
> Well, at least it's better than inlining it...
>
> I would've expected to see VIRTIO_PCI_PROXY(obj) defined as
> OBJECT_CHECK(VirtIOPCIProxy, (obj), TYPE_something) somewhere.
>
> If, as you imply with "data path", this were a problem, you could just
> do VirtIOPCIProxy *proxy = (VirtIOPCIProxy *)d inline to allow for
> VIRTIO_PCI_PROXY() to be used in the QOM sense elsewhere.
>
> Andreas
I don't get it - where?
Since we don't do runtime checks we need container_of -
safer than a plain cast.
Anyway, when you start doing your QOM conversions it will be
easy to do what you like.
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
