From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K94tW-0005BB-PF for qemu-devel@nongnu.org; Wed, 18 Jun 2008 17:08:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K94tV-0005Az-N3 for qemu-devel@nongnu.org; Wed, 18 Jun 2008 17:08:42 -0400 Received: from [199.232.76.173] (port=43671 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K94tV-0005Aw-8z for qemu-devel@nongnu.org; Wed, 18 Jun 2008 17:08:41 -0400 Received: from hs-out-0708.google.com ([64.233.178.247]:22544) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K94tT-0004cR-Sj for qemu-devel@nongnu.org; Wed, 18 Jun 2008 17:08:40 -0400 Received: by hs-out-0708.google.com with SMTP id k27so32947hsc.2 for ; Wed, 18 Jun 2008 14:08:32 -0700 (PDT) Message-ID: <4859793E.1060700@codemonkey.ws> Date: Wed, 18 Jun 2008 16:08:14 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU configuration files References: <48595024.7050400@bellard.org> In-Reply-To: <48595024.7050400@bellard.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Fabrice Bellard wrote: > Hi, > > My snapshot of the "object based" QEMU configuration system can be > found at http://bellard.org/qemu/patches . I only tried it for x86 > targets. It is not yet in committable state and comments are welcome ! I've only done a very quick high level review. I'll try to do a more thorough one soon. My first impressions are very positive. I think it would be better to decentralize class registration but I don't think that's a very hard change to make. > General ideas: > > - User preferences and machine definitions are separated. User > preferences are in ~/.qemu/config for Unix systems. Machine > definitions can override user preferences but I believe it should be > the exception. Ack. I think this is pretty important. > - Command line options override the user preferences and machine > definitions. > > - Machine definitions contain machine parameters and device > definitions. Device definitions are used to create new devices not > instanciated in the hardcoded machine definition such as PCI and USB > devices. > > There are many details which need clarification, in particular: > > - PCI, IDE, SCSI and buses naming. It is important if we want to be > able to dynamically instantiate complicated bus topologies. > - USB port naming > - Is it worth specifying board specific network controllers as > separate devices (I tried to do that for smc91c111 devices) ? A > simpler solution would be to add new machine parameters to do that. > - It would be logical to define QEMUDevice for every instanciated > device and that register_savevm() use QEMUDevice as parameter, but it > requires more changes in the code. Indeed. QEMUDevice is a good abstraction as it can be also be used to introduce per-device locking which will help parallelize things with KVM. Regards, Anthony Liguori > - Is it worth handling class defaults parameters ? I find the current > implementation too complicated. > > Fabrice. > > >