From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M2OGF-0007kR-4P for qemu-devel@nongnu.org; Fri, 08 May 2009 07:29:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M2OG9-0007bj-6G for qemu-devel@nongnu.org; Fri, 08 May 2009 07:29:01 -0400 Received: from [199.232.76.173] (port=51796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M2OG8-0007bR-U6 for qemu-devel@nongnu.org; Fri, 08 May 2009 07:28:57 -0400 Received: from mx20.gnu.org ([199.232.41.8]:16032) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M2OG8-0005aV-QQ for qemu-devel@nongnu.org; Fri, 08 May 2009 07:28:56 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M2OG7-00009H-Is for qemu-devel@nongnu.org; Fri, 08 May 2009 07:28:55 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC] New device API Date: Fri, 8 May 2009 12:28:52 +0100 References: <200905051231.09759.paul@codesourcery.com> <4A0390DC.2010908@redhat.com> In-Reply-To: <4A0390DC.2010908@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905081228.53028.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zachary Amsden Cc: qemu-devel@nongnu.org > > The attached patch is my attempt at a new internal API for device > > creation in qemu. >... > I think the general direction is good, and this is sorely needed, but I > think having a fixed / static device struct isn't flexible enough to > handle the complexities of multiple device / bus types - for example, > MSI-X could add tons of IRQ vectors to a device, or complex devices > could have tons of MMIO regions. > > I think a more flexible scheme would be to have a common device header, > and fixed substructures which are added as needed to a device. I'm not sure how much benefit this gives in practice, or how much it's worth catering for the "same" device that can be attached to different busses. While e.g. both PCI and non-PCI devices have MMIO regions and IRQ sources, I'm not sure how much can be shared between the two. I suspect the common infrastructure extended as far as cpu_register_io_memory/qemu_irq (or equivalent), but using the same API for the bus/device interaction is more trouble then it's worth. While a fancy multiple inheritance system like you describe is in interesting idea, It feels over-engineered for this particular problem. > The config issue is certainly a very important problem to address. I > think it should be noted there are three types of configuration data, > all of which are ontologically different. There are: > > 1) Static per-device configuration choices, such as feature enable / > disable, framebuffer size, PCI vs. ISA bus representation. > > 2) Dynamic per-device data. I think these two largely fall out together. Once you've determined that you're dealing with a PCI device, all the associated dynamic PCI data follows directly from that. > 3) Implementation specific data. Pieces of data which are required for > a particular realization of a device on the host, such as file > descriptors, call back functions, authentication data, network routing. We already have things like CharDevice and BlockDriverState to isolate devices from the host implementation. In the past this is the distinction I've made between user-level config and machine config. Paul