From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NsHsu-0000KU-E1
	for qemu-devel@nongnu.org; Thu, 18 Mar 2010 11:43:44 -0400
Received: from [199.232.76.173] (port=44799 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NsHss-0000HZ-FD
	for qemu-devel@nongnu.org; Thu, 18 Mar 2010 11:43:42 -0400
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <kraxel@redhat.com>) id 1NsHsr-0002KC-MQ
	for qemu-devel@nongnu.org; Thu, 18 Mar 2010 11:43:42 -0400
Received: from mx1.redhat.com ([209.132.183.28]:37641)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1NsHsr-0002K3-AB
	for qemu-devel@nongnu.org; Thu, 18 Mar 2010 11:43:41 -0400
Received: from int-mx03.intmail.prod.int.phx2.redhat.com
	(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2IFhcDU016420
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Thu, 18 Mar 2010 11:43:39 -0400
Message-ID: <4BA24A26.5030602@redhat.com>
Date: Thu, 18 Mar 2010 16:43:34 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
References: <cover.1268765204.git.quintela@redhat.com>	<20100318064015.GA16973@redhat.com>
	<m3iq8unksl.fsf@trasno.mitica>
In-Reply-To: <m3iq8unksl.fsf@trasno.mitica>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>

   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