- Changed variable type of the plugin_t "type" member from enum to Bit16u.
- Added support for returning device flags with the new mode PLUGIN_FLAGS in
the plugin entry functions. It is currently only used for devices that can
be connected to a PCI slot.
- Code cleanup in core device plugins: checking type no longer necessary.
- The "non-plugin" mode now also uses the "loadtype" member of plugin_t.
TODO: Change PCI slot options to bx_param_enum_c and build the choices list
using the new capabilities of the plugin API.
- Disable port "options" parameter after successful connect. While connected,
a device may install runtime options to control it's behaviour.
- Added enable handlers for the "options" parameter to ensure an attempt to
change the device while connected doesn't enable it.
- Some related code cleanups.
- Changed some bx_param_c member types and related code to bool.
- Added bx_param_string_c method get_enable_handler() for the use in gui dialog
dependency processing.
- Call the enable_handler (if present) when processing dependent list in the wx
and win32 ParamDialog code.
device handling. Added some code to handle plugins that provide more than one
device type (usb_hid, usb_msd) or with different name (usb_cbi). The device
type member is now only used by multi-function devices.
- USB hub: disable device "options" parameter if device is set to "none".
- USB hub: handle device disconnect in runtime_config().
- Removed handling of USB device type in host controllers and external hub.
- Fixed USB devices list by adding a terminating NULL entry.
- Disable USB device options parameter if device is set to "none".
- Related documentation updates.
- Moved main option from the portX parameter to the optionsX parameter. Added
new option "path" for the disk, cdrom and floppy devices, "ports" for the
USB hub and "file" for the USB printer. The legacy syntax is still supported.
- Register USB device state after init() to ensure all options that may have
effect on the save/restore list are applied.
- Report available devices on top of log file similar to hdimage, network and
sound modules.
- Changed USB device type variable typein host controllers to int.
- Prepared improved usbdev_ctl init / exit implementation.
- TODO: Create list of USB devices dynamicly from available plugins.
- Fixed loading of all plugins with one type using wildcard.
- Reduced maximum length of line when listing available modules for hdimage,
network and sound.
hardcoded one. In plugins mode now all plugins with PLUGTYPE_GUI can be used.
Added similar code for the case plugins are disabled. The macros
PLUG_get_plugins_count() and PLUG_get_plugin_name() can be used in both cases.
- BXRS_PARAM_BOOL macro should be used for bool type members only.
- Fixed usage of wrong BXRS macro for numeric member in usb_hid.cc.
- New PCI parameter "advopts" must be saved in config.
- FIXME: Bochs hangs at startup in restore mode.
- Added special mode to all plugin entry functions that returns the plugin type.
- The plugins search function now temporarily loads all available plugins and
reads the plugin type using the new mode PLUGIN_PROBE.
- Added "loadtype" to the plugin structure to store the type used for plugin
loading (currently only the voodoo plugin provides two types).
module code. Sound driver names are now stored as string constants instead
of hardcoded values. Available modules are detected at Bochs startup and stored
in a string array before initializing options. In the plugins case available
modules are read from the plugins list. If plugins are off, the registry of
bx_sound_lowlevel_c is used. Related changes similar to the hdimage and
network modifications.
handling. Networking module names are now stored as string constants instead of
hardcoded values. Available modules are detected at Bochs startup and stored in
a string array before initializing options. In the plugins case available
modules are read from the plugins list. If plugins are off, the eth_locator_c
registry is used. Related changes in all parts of Bochs that need the
networking stuff.
TODO #1: Sound drivers could be handled in a similar way.
