RE: [Qemu-devel] [PATCH][RFC] system emulator modularization

[Andreas Bollhalder]

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: address@hidden 
> [mailto:address@hidden On 
> Behalf Of Magnus Damm
> Sent: Sunday, January 16, 2005 12:52 AM
> To: address@hidden
> Subject: [Qemu-devel] [PATCH][RFC] system emulator modularization
> 
> 
> Heya,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> check(): 
> 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.
> 
> 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.
> 
> 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().
> 
> >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:
> 
> -x label=module[:args]  create one instance of module called label
> 
> 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:
> 
> -x vga0=cirrus-vga
> -x vga1=std-vga
> -x nic0=ne2000:mac=0x0080deadbe
> -x pcibus0=pcibus:vga0,vga1,nic0
> -x cpu0=x86:nommx
> -x mypc=pc:cpu0,pcibus0
> 
> 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.
> 
> 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.
> 
> / magnus
>