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