From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3Ybl-0004og-Hd for qemu-devel@nongnu.org; Mon, 11 May 2009 12:44:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3Ybh-0004o7-4A for qemu-devel@nongnu.org; Mon, 11 May 2009 12:44:05 -0400 Received: from [199.232.76.173] (port=51755 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3Ybg-0004nz-So for qemu-devel@nongnu.org; Mon, 11 May 2009 12:44:00 -0400 Received: from mx20.gnu.org ([199.232.41.8]:60886) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M3Ybg-0002mb-GO for qemu-devel@nongnu.org; Mon, 11 May 2009 12:44:00 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M3Ybf-0002m6-9L for qemu-devel@nongnu.org; Mon, 11 May 2009 12:43:59 -0400 From: Paul Brook Date: Mon, 11 May 2009 17:43:54 +0100 References: <1242052009-27339-1-git-send-email-aliguori@us.ibm.com> <200905111716.35553.paul@codesourcery.com> <4A085040.3000409@us.ibm.com> In-Reply-To: <4A085040.3000409@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111743.55077.paul@codesourcery.com> Subject: [Qemu-devel] Re: [PATCH 0/4][RFC] Add module infrastructure to QEMU List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org > > I'm not convinced virtio is as much of a separate entity as you think it > > is. It's certainly not a bus. It's an implementation detail that happens > > to be shared by several devices. > > It is once you abstract out the transport API from the transport > implementation. We fall short here in QEMU today mainly for better > integration with how machines are created today. I'd like to refactor > the QEMU virtio code though to be closer to the Linux side of things. I > see a module mechanism like this as a prereq for doing such a refactoring. I think it's only a prerequisite if you want a single "virtio" device that then magically morphs into a specific device based on its config. In practice I don't think this is really useful, and the virtio init is driven directly from the host binding. i.e. you have separate virtio-net-pci, virtio-blk-pci, virtio-net-s390, etc. devices in the same way that other pci devices are top level entities. I've already got a patch I'm hoping to push out soon that implements a different virtio binding. Paul