From 2f2752dd74ae49ddc05c95388add9b34a466f1cb Mon Sep 17 00:00:00 2001 From: Volker Ruppert Date: Fri, 5 Mar 2021 15:45:02 +0000 Subject: [PATCH] Some more documentation updates and additions (new section for the siminterface class). --- bochs/doc/docbook/development/development.dbk | 68 +++++++++++++++++-- 1 file changed, 63 insertions(+), 5 deletions(-) diff --git a/bochs/doc/docbook/development/development.dbk b/bochs/doc/docbook/development/development.dbk index 0c88e8bf9..f3fb2f7a7 100644 --- a/bochs/doc/docbook/development/development.dbk +++ b/bochs/doc/docbook/development/development.dbk @@ -250,7 +250,7 @@ For the configuration interface there are also some different implementations: t doc/docbookthe Bochs documentation in DocBook format doc/manBochs manual pages docs-htmlold Bochs documentation in HTML (will be replaced by DocBook) -guidisplay libraries (guis), the simulator interface and text mode config interface +guidisplay libraries (guis), the simulator interface, the parameter tree and text mode config interface gui/bitmapsbitmaps for the headerbar gui/fontthe default VGA font used by most of the display libraries gui/keymapskeymaps for the keyboard mapping feature @@ -391,6 +391,44 @@ If static methods are used then BX_CPU_THIS_PTR evaluates to BX_CPU(0)->. Ugly, isn't it? +
The simulator interface + +The central object for the communication between several Bochs componnents is +the simulator interface (AKA "siminterface"). It especially makes the separation +between the configuration interface and the simulator possible. These jobs are +done using the SIM object: + +event handling +parsing / writing config file +accessing the parameter tree +begin and quit simulation +execute save and restore code +adjust log options +access to the debugger core + +The event handling supports both synchronous and asynchronous types. In case of +a synchronous event, the sender waits until the receiver has processed the +event (finally setting return code). Asynchronous events are simply added to the +event queue and fetched from it later when the receiver processes event. The +event handling is important if a multithreaded implementation of gui and config +interface like wxWidgets is used. An example for the event handling is the +procedure after pressing the "snapshot" tool bar button: + +wxmain.cc: MyFrame::OnToolbarClick() adds BX_ASYNC_EVT_TOOBAR to the queue +wx.cc: bx_wx_gui_c::handle_events() fetches event and calls gui button handler +gui.cc: bx_gui_c::snapshot_handler() calls siminterface to ask for a file name +siminterface.cc: bx_real_sim_c::ask_filename() creates event BX_SYNC_EVT_ASK_PARAM and waits for completion +siminterface.cc: bx_real_sim_c::sim_to_ci_event() calls registered config interface function +wxmain.cc: SimThread::SiminterfaceCallback2() creates a wxCommandEvent +wxmain.cc: MyFrame::OnSim2CIEvent() calls handler for this event +wxmain.cc: MyFrame::HandleAskParamString() calls wxFileDialog() +wxmain.cc: MyFrame::OnSim2CIEvent() calls SimThread::SendSyncResponse to set return code() +wxmain.cc: SimThread::SiminterfaceCallback2() returns event result +siminterface.cc: bx_real_sim_c::ask_filename() returns file name if successful +gui.cc: bx_gui_c::snapshot_handler() saves simulation screenshot to file + + +
The configuration parameter tree Starting with version 1.3, the Bochs configuration parameters are stored in parameter @@ -2995,13 +3033,33 @@ interface:
+
Plugin file names + +The plugin interface expects a special file name format that depends on the +plugin type and platform. On Linux and other platforms using "libtool" the +plugin file for the CMOS device has this name: + +libbx_cmos.so + +On Windows platforms the output file is a DLL and the name is slightly different: + +bx_cmos.dll + +The names of device plugins are created from the base name of source files like +the example above. Networking module names traditionally start with "eth_" +and sound driver names start with "sound". For gui and disk +image format modules an extension has been added to the base name ("_gui" +/ "_img"). + +
Plugin types Device plugins are categorized into some types depending on their purpose. Some devices are mandatory for the x86 PC emulation or need to be initialized early -to make other device work correctly. A plugin can be loaded only one single -time, but some types may create multiple objects. This is the full list of -plugin types defined in extplugin.h with some description: +to make other devices work correctly. A plugin can be loaded only one single +time, but some types may be capable to create multiple objects. This is the full +list of plugin types defined in extplugin.h with some +description: Plugin types @@ -3076,7 +3134,7 @@ plugin types defined in extplugin.h with some description: Sound driver selected with the sound option libsoundmodule_plugin_entry bx_sound_lowlevel_c -One plugin per type only +Up to 4 plugins supported