Bryce Denney wrote:
>
> Sorry for the cross-posting. I thought bochs people would want to hear
> about IO device modularization as well.
No problem, this is certainly pertinent to both projects.
> 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.
I noticed work had been done in bochs to the bx_options processing.
I definitely want to delete that structure as it is now, and make
things more modular. I'll have a closer look at what you have coded
in bochs for options parsing. As one of the goals of mine is to
merge with the bochs device models, it will be good if I can find
a mechanism which is not far from what you have. More after I
have a better look...
Ultimate (and soon), it'd be cool to have a merge of the following items:
IO devices models (as plugins)
BIOS
GUI
Ideally the entire GUI could be shared. Also, any extra interfaces,
for example one for guest-specific drivers to talk to code outside the VM.
As far as compiling in devices static... I haven't done any work here, but
once you've modularized devices it should be quite simple to #ifdef compilation
so that a wrapper function can call them statically, rather than load them
dynamically. There are only a couple functions (entry points) in each device,
which register facilities etc via a defined plugin interface. So you can
have a wrapper function just call all of these. Though, conditionally you
have to give the enty points different names for a non-plugin environment,
since for plugins, every plugin contains the same entry points.
I would say this would be the easiest of the issues. Though it'd
be cool if plugins could be implemented on all platforms, rather than
always dumbing down to some weak-link platform.
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/