From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NsM0I-0005en-F7 for qemu-devel@nongnu.org; Thu, 18 Mar 2010 16:07:38 -0400 Received: from [199.232.76.173] (port=52376 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NsM0H-0005e1-Q7 for qemu-devel@nongnu.org; Thu, 18 Mar 2010 16:07:37 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NsM0G-0006NI-Iz for qemu-devel@nongnu.org; Thu, 18 Mar 2010 16:07:37 -0400 Received: from mail-fx0-f214.google.com ([209.85.220.214]:61013) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NsM0G-0006N5-Af for qemu-devel@nongnu.org; Thu, 18 Mar 2010 16:07:36 -0400 Received: by fxm6 with SMTP id 6so1033698fxm.2 for ; Thu, 18 Mar 2010 13:07:34 -0700 (PDT) Message-ID: <4BA287FC.3090605@codemonkey.ws> Date: Thu, 18 Mar 2010 15:07:24 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups References: <20100318064015.GA16973@redhat.com> <4BA24A26.5030602@redhat.com> <4BA2569A.3040600@redhat.com> In-Reply-To: <4BA2569A.3040600@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, Juan Quintela On 03/18/2010 11:36 AM, Gerd Hoffmann wrote: > Hi, > >> But I still think that this is independent that VirtIO being 1st (or >> not) memer of VirtIOBlock. > > There is no strong reason for this other than memory allocation. As > long as virtio_common_init() does the allocation there is no way > around VirtIODevice being the first member. If this changes (and we > must change it if we want embed VirtIODevice and superclasses into > other structs) no reason is left. > > Just changing it for the snake of change isn't a good reason either. > But if it helps cleaning the code we can change it without running > into trouble. You can't cast VirtIODevice to VirtIOBlock any more, > but you don't really want to anyway for type checking reasons. It's almost certainly not worth the effort, but the proper way to model is it probably to have a VirtioIOPCIBus that is a PCIDevice. The VirtIOPCIBus then creates a single VirtIODevice. The VirtIODevice would then take a VirtioTransport which would be implemented as part of the VirtIOPCIBus. Regards, Anthony Liguori > cheers, > Gerd > >