declared as bx_param_c * types in the bx_options structure. They are
initialized in main.cc (bx_init_options) with default values.
Access to parameters of this type should always be like this:
bx_options.mouse_enabled->get ();
bx_options.mouse_enabled->set (newval);
Eventually I will be transferring all options to this format.
when main.cc no longer had one. Now compiling with debugger is working
with the control panel. To get the control panel, you have to click
the snapshot button, and to get the debugger, you have to press ^C.
These should be better integrated (maybe a control panel menu choice
that jumps into the debugger and a debugger command that starts the
runtime control panel...)
better name given what the options actually are.
- now runtime menu behaves more like the others: it updates its floppy
disk image, etc.
- add "ask" as a legal choice for log action
- now runtime menu has both ways of editing log options
panel. It gives the user the option of continue this time, continue
and never ask again for this type of log message, or die.
- the communication between control.cc and siminterface.cc is still
somewhat crude. I'm trying to implement it so that a network
protocol based on this interface will be simple. I'll get this cleaned
up soon.
BX_USE_CONTROL_PANEL is set. I put the #if...#endif thing around
the entire file in siminterface.cc and control.cc so that it's safe
to compile them in either case.
writes a bochsrc for you.
- since there were two options related to logging, I moved them both
into a new struct called bx_log_options. This follows the pattern
used by other devices.
- in control.cc: removed option 1 from main menu, the one that said
"Read options from bochsrc.txt." This was identical to choosing
the next option, "Read options from..." and only saved you one
keystroke, so I removed it.
gui/control.cc and the simulator. Now all communication between
the control panel and the rest of bochs goes through an object
called bx_simulator_interface_c.
To see the commit logs for this use either cvsweb or
cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files.
In general this provides a generic interface for logging.
logfunctions:: is a class that is inherited by some classes, and also
. allocated as a standalone global called 'genlog'. All logging uses
. one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this
. class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros
. respectively.
.
. An example usage:
. BX_INFO(("Hello, World!\n"));
iofunctions:: is a class that is allocated once by default, and assigned
as the iofunction of each logfunctions instance. It is this class that
maintains the file descriptor and other output related code, at this
point using vfprintf(). At some future point, someone may choose to
write a gui 'console' for bochs to which messages would be redirected
simply by assigning a different iofunction class to the various logfunctions
objects.
More cleanup is coming, but this works for now. If you want to see alot
of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1.
Comments, bugs, flames, to me: todd@fries.net
signal. First, selection of the GUI should cause BX_GUI_SIGHANDLER to
be defined in config.h.in. Then, the GUI should define member functions
Bit32u get_sighandler_mask ();
void sighandler (int sig);
The mask function returns a bitfield where one bit corresponds to each
signal. For any signal whose bit is set to 1 in the return value of
get_sighandler_mask, the gui will control that signal. When the signal
arrives, bx_gui.sighandler(sig) will be called by bx_signal_handler,
instead of the default behavior of that signal.
