This is an early RFC, the work is in very early stages, I am interested
to know if there is a consensus that this is the right path.
The main benefit of QOMifying the qemu machine would be the possibility
to have options per machine type and not global.
However, there are other benefits as:
- accessing qemu object properties instead of a global QemuOpts
list from different code subsystems.
- improving the machine "initialization" code (compat and stuff)
- getting more close to QOM's vision of single interface for
device creation and so on.
Basically the series aims (in the long run) to convert:
QEMUMachine -> QemuMachineClass
QEMUMachineInitArgs -> QemuMachineState.
As a first step, in order to make possible an incremental development,
both QEMUMachine and QEMUMachineInitArgs are being embedded into the
new types.
Your comments are welcomed,
Marcel
Marcel Apfelbaum (5):
hw/core: introduced qemu machine as QOM object
vl: use qemu machine QOM class instead of global machines list
hw/boards: converted current_machine to be an instance of
QemuMachineCLass
hw/machine: add qemu machine opts as properties to QemuMachineState
vl.c: set current_machine's properties
device-hotplug.c | 4 +-
hw/core/Makefile.objs | 2 +-
hw/core/machine.c | 289 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/hw/boards.h | 55 +++++++++-
qmp.c | 7 +-
vl.c | 122 ++++++++++++++-------
6 files changed, 435 insertions(+), 44 deletions(-)
create mode 100644 hw/core/machine.c
--
1.8.3.1
