qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
Date: Thu, 18 Mar 2010 16:43:34 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

  Hi,

I think we should move away from struct layout assumptions that
DO_UPCAST enforces, and to use container_of where possible.
I'll post a series shortly that do this for virtio.

Not in this case.  qdev needs it to be in that order, and that will not
change without changing everything again.   Look at the rest of hw/*.

The only "sane" way of doing OOP on C is to use the super-class memmbers as the
1st member of the sub-classes.  That will not change anytime soon.  And
trying to "emulate" multiple inheritance in C is completely "insane".

The improtant bit is the patch is:

+    VirtIODevice *vdev = virtio_common_init("virtio-blk", VIRTIO_ID_BLOCK,
+                                            sizeof(struct virtio_blk_config),
+                                            sizeof(VirtIOBlock));
+    s = DO_UPCAST(VirtIOBlock, vdev, vdev);

You can't have a virtio_common_init() that initializes the shared bits
ad init them in the middle of nowhere.  It _needs_ to be at the
beginning of the shared struct.

No. qdev requires it for devices because it does the allocation for you. qdev does *not* require it for busses for example. You can easily embed the bus struct into the device state of the parent device:

struct scsi_hba {
   PCIDevice pcidev;
   SCSIBus bus;
   /* more device state here */
};

Moving virtio into the same direction is a good thing IMHO. We can have something like this then:

struct VirtioBlockPCI {
   VirtIOPCIProxy proxy;
   VirtIOBlock block;
};

The messy qdev property handing for virtio (copying stuff between vdev and proxy) can go away then. And I think it also simplifies things alot for vmstate.

cheers,
  Gerd





reply via email to

[Prev in Thread] Current Thread [Next in Thread]