From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbuAO-00045I-OH for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:23:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbuAK-00066R-KB for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:23:40 -0500 Received: from greensocs.com ([87.106.252.221]:60520 helo=s15328186.onlinehome-server.info) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbuAK-00066N-Dy for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:23:36 -0500 Message-ID: <50AF86F7.5070508@greensocs.com> Date: Fri, 23 Nov 2012 15:23:51 +0100 From: Konrad Frederic MIME-Version: 1.0 References: <1353595852-30776-1-git-send-email-fred.konrad@greensocs.com> <1353595852-30776-3-git-send-email-fred.konrad@greensocs.com> <20121123122941.GA29800@stefanha-thinkpad.redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 2/3] virtio-pci : add a virtio-bus interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: aliguori@us.ibm.com, e.voevodin@samsung.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, Stefan Hajnoczi , cornelia.huck@de.ibm.com, afaerber@suse.de On 23/11/2012 13:34, Peter Maydell wrote: > On 23 November 2012 12:29, Stefan Hajnoczi wrote: >> On Thu, Nov 22, 2012 at 03:50:51PM +0100, fred.konrad@greensocs.com wrote: >>> +static const struct VirtioBusInfo virtio_bus_info = { >>> + .init_cb = virtio_pci_init_cb, >>> + .exit_cb = virtio_pci_exit_cb, >>> + >>> + .virtio_bindings = { >> Eventually VirtIOBindings can probably be inlined into VirtioBusInfo. I >> don't see a need for separate structs. > I agree. It might (or might not) be convenient to retain it > temporarily while converting all the transports, but > VirtIOBindings is part of the old code which we're trying > to refactor here, and I'd expect it to go away when we're done. > > -- PMM Yes, for the moment, I didn't refactor this VirtIOBindings, so it is better to separate struct to keep the virtiodevice binding function.