Ramon von Handel wrote:
> I completely overhauled the new code.
> I moved all of it into the directory
> user/plugins/bochs/, and made new makefiles.
I'm a bit uneasy about applying this change, not because I don't like
it, but for a technical reason: CVS doesn't really know how to rename
or move directories. So you can either remove the old directory by force
and start from scratch in the new one (in which case you loose all change
log data), or else you are stuck with the old, empty directories ...
Now at this stage of the project, we don't really have all that much
change logs yet, so if necessary, I'll do a change like that. But I'd
like to discuss the new design and directory structure first, so that we
at least don't have to change it all again if it turns out something
wasn't quite right the first try ;-)
One point that I'm unsure about is just what exactly a 'plugin' is
supposed to be. I agree that it is probably a good thing to modularize
the emulated hardware devices to a point where you can just 'plug in'
a hardware emulator library like you'd plug a PCI card into a real
computer. But for this to work, we have to define interfaces that
allow the plugins to claim resources (like hardware does), e.g. IRQs,
I/O ports, memory address ranges, DMA channels ... They will also need
to use shared data, like a global emulation time frame. This means that
a plugin might need to export more than a single entry point (or else,
call back to routines from the base?).
Is there anything else, except hardware models, that you expect to fit
into the plugin scheme? You mentioned in another post a debugger; what's
the benefit over having the debugger integrated in the main code?
Another question is about naming: as we'll want to take over more
hardware models from Bochs, should we place all of them together into
a single plugin called 'bochs', or rather split them up into 'console',
'pic/pit', 'ide' etc.? Kevin, you'll know best what the easiest way
would be here from the p.o.v. of the Bochs code ...
What about the GUI code? Should this stay inside a plugin, or rather
become part of the main code? GUI buttons will have to be acted upon
by the main code, I suppose ...
Finally, while shared libraries are great for flexibility, they can
be a hassle to install; having the option of compiling a certain
set of devices into a single executable that you can just copy and
run everywhere would be nice IMHO.
(Please note that I'm not saying all problems must be solved before I'll
apply anything to the tree; I'd just like to have a plan how at least
the directory layout is supposed to look like, that will survive the
next few updates ;-))
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
