Sorry for the cross-posting. I thought bochs people would want to hear
about IO device modularization as well.
On Wed, 15 Aug 2001, Kevin Lawton wrote:
> - "Kevin P. Lawton" <[EMAIL PROTECTED]>: Wed Aug 15 18:32:28 CEST 2001
> Many more moularization changes. Now, all the IO devices which are
> compiled by default, use a plugin interface and are loaded as
> individual plugins. I haven't cleaned up some of the devices which
> are not compiled in by default.
> Only tested and fixed the conf/ files for freedos and win95.
> If you try with your own conf files, you must modify them
> like 'freedos' or 'win95'. This interface will be in flux for
> a while, as I'm making several passes through the code to
> clean it up, while keeping things in working condition.
> Currently, options are set through the old bx_options structure,
> but next I plan to fix this, passing options directly to each
> plugin via a more modular/intelligent get/set option interface.
I have put a lot of time and coding into a get/set parameter interface for
Bochs, in the context of moving toward a graphical configuration
interface. In the current Bochs CVS version, each parameter is associated
with a small data structure which encodes its type, short name, long
description, and for integers the min and max allowed values. With this
strategy, you have to code the parsing, user interaction, loading/saving,
range checking, etc. once per data type instead of once per parameter.
The code is in gui/siminterface.h and gui/siminterface.cc in the bochs CVS
tree. Yes, it's written as C++ objects and I know that's an issue.
All these parameter data structures are still contained in bx_options at
the moment, but eventually I expect to move them into the objects that
they control. This should help when setting up plugins. To configure a
device, you just need to find its list of parameters and call the get/set
methods on the parameters.
I'm willing to put in some time to make my get/set interface work for both
plex and bochs, if it seems appropriate. Then if Bochs ever gets its act
together and writes a GUI configuration interface, it can easily be
adapted to plex86, and vice versa.
> Here is a list of the devices which are now plugins (an
> excerpt from a conf file):
>
> plugin = ./plugins/bochs/iodev/cmos.so
> plugin = ./plugins/bochs/iodev/dma.so
> plugin = ./plugins/bochs/iodev/system.so
> plugin = ./plugins/bochs/iodev/vga.so
> plugin = ./plugins/bochs/iodev/serial.so
> plugin = ./plugins/bochs/iodev/parallel.so
> plugin = ./plugins/bochs/iodev/keyboard.so
> plugin = ./plugins/bochs/iodev/floppy.so
> plugin = ./plugins/bochs/iodev/harddrv.so
>
> Also as I make passes through the code, I'll clean up the plugin
> interface too. It's a little hacky in parts. But if I redesign
> it all in one shot, I'm sure I'm going to introduce some big errors
> which will make testing/debugging really difficult.
In your plugin interface, is it possible to compile everything in
statically instead of using shared objects? Since Bochs is aiming for
portability to many platforms, it will be important to have a backup plan
for those platforms where nobody has bothered to make shared objects work
yet.
Thanks,
Bryce
