From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CqBJn-0007Mi-74 for qemu-devel@nongnu.org; Sun, 16 Jan 2005 09:23:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CqBJl-0007M5-OA for qemu-devel@nongnu.org; Sun, 16 Jan 2005 09:23:50 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CqBJl-0007LO-LN for qemu-devel@nongnu.org; Sun, 16 Jan 2005 09:23:49 -0500 Received: from [62.2.95.247] (helo=smtp.hispeed.ch) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CqB62-0004DF-R5 for qemu-devel@nongnu.org; Sun, 16 Jan 2005 09:09:39 -0500 From: "Andreas Bollhalder" Subject: RE: [Qemu-devel] [PATCH][RFC] system emulator modularization Date: Sun, 16 Jan 2005 15:06:10 +0100 Message-ID: <000001c4fbd4$881da820$6401a8c0@geodb.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: Reply-To: bolle@geodb.org, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Magnus Damm' , qemu-devel@nongnu.org I would welcome this concept for configuring QEmu. Also, if this directives could be stored in a INI file, it would be very cool. Andreas > -----Original Message----- > From: qemu-devel-bounces+bolle=3Dgeodb.org@nongnu.org=20 > [mailto:qemu-devel-bounces+bolle=3Dgeodb.org@nongnu.org] On=20 > Behalf Of Magnus Damm > Sent: Sunday, January 16, 2005 12:52 AM > To: qemu-devel@nongnu.org > Subject: [Qemu-devel] [PATCH][RFC] system emulator modularization >=20 >=20 > Heya, >=20 > I have recently been scratching one of my favourite itches: > modularization. QEMU has some well defined interfaces, but one of the > bottlenecks when it comes to add and test new code is IMHO the command > line options. The current way to do it is pretty straight forward - > just add your new command line options to vl.c and off you go. > However, this leads to some kind of option space pollution. With other > words, I do not think the current solution scales wery well and it > would be a shame to make it harder to add code to QEMU than it has to > be. >=20 > So, what I would like to add to QEMU is some kind of module support. > My idea consists of two basic building blocks: modules and labels. >=20 > A module is some kind of well defined function of the emulator, maybe > code that emulates one chip, or perhaps some core emulator code. You > could call it a class. >=20 > A label is a named instance of a module. Each label is associated with > a private data area that contains all state about the label. Pretty > much an object. >=20 > So, to be able to use any module you have to create an instance of it > by creating a label. When a label is created it is possible to pass > parameters to the instance. Each module has a set of operations, I > suggest the following: >=20 > check():=20 > Called when the label is created. Used to validate module parameters. > Should not allocate any data, private data belonging to label is > already allocated by global module code. Must make sure that the > module parameters are saved in a standardized endian-independent > format - I suggest network byte order. >=20 > start(): > Called when the label is enabled. The private data is still in network > byte order, now it is time for the module to convert the data to > native byte order, allocate data and register itself or whatever. This > start operation is used both for restore from a saved state and for a > clean start. >=20 > stop(): > Called when the label is disabled, ie when the emulator is shut down > or when state is saved. The module should unregister itself and > convert the private data into network byte order. After stop() it > should be possible to use the same private data and perform start(). >=20 > >From the command line it should be possible to create/change labels > and to list availible modules. The attached patch lists modules after > the help text, and the temporary option -x is currently used to create > a label. From the help text: >=20 > -x label=3Dmodule[:args] create one instance of module called label >=20 > The grand plan (not finished yet if ever) is that labels should depend > on each other and something like this could be used to start the > emulator with 2 vga cards and one nic on the pci bus: >=20 > -x vga0=3Dcirrus-vga > -x vga1=3Dstd-vga > -x nic0=3Dne2000:mac=3D0x0080deadbe > -x pcibus0=3Dpcibus:vga0,vga1,nic0 > -x cpu0=3Dx86:nommx > -x mypc=3Dpc:cpu0,pcibus0 >=20 > This idea together with predefined profiles (collection of predefined > labels) and that it should be possible to override predefined labels > with user-defined ones would make QEMU pretty flexible IMHO. >=20 > The attached patch does not do anything useful, it just contains some > module code and a module skeleton. The code is pretty much a big hack, > but I included it just to let you see. The module code is "inspired" > from the Linux kernel, but improved to support instances. Module > information is stored in a special section, just link in the code > between module.o and module_last.o and everything should work by > itself. >=20 > / magnus >=20