Ulrich Weigand wrote:
> 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 ...
Yes, I am aware of that... I usually solve the problem by
messing directly in the CVSROOT directory, but as nobody here
has root access on fastxs.net that is probably not possible.
> 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 ;-)
That can never do any harm... ;)
> 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?).
Absolutely. I go for the callbacks -- note that I used a
callback for the debugger, though that should be temporary
until interrupt allocation is implemented. As I see it, the
user program should have a set of well-defined entry points
that a plugin can call to allocate resources; on every resource
allocation the plugin provides a callback address which is
invoked when the corresponding event has occured.
> 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?
That you can easily switch to another debugger. I created
a GDB stub; Julian can create a "real" debugger. Somebody
else can create another version. All of these have large pros
and cons. It would be great if I can just pick which debugger
I'd like to use at runtime, depending on the situation.
In principle, I'd like everything that's not very basic to be
a plugin. Quite aside from the obvious flexibility of this
method (I can strip the VM as much as I want, if I need to !
And OTOH, if I wanted to I could make WINE a plugin ;)),
it also has another advantage: by forcing a specific interface
you avoid making a mess of interdependencies. All in all, I
think plugins are a good move. They're what I've had in mind
since the beginning, anyway.
> 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 ...
Ideally, I'd prefer each device to be a different plugin.
However, because these were ported from BOCHS it wasn't
easy to separate them out, so for now I put them in one
plugin. Ultimately it would be a good idea to create a
'BOCHS support library' and link it in with every plugin ---
that way we can use hardly-modified BOCHS source
while retaining the advantage of separate plugins.
This is similar to the method the OSKIT uses to port
linux and freebsd drivers.
> 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 ...
Why not make the GUI a separate plugin... then you can
replace the GUI at will. That's very flexible. Of course,
I don't know how viable this is... I guess the GUI would
have to have a standardised interface of its own.
However, plugins should be able to call each other ---
just make sure you load them in the right order
(warning, right now plugins are initialized in the
opposite order as they occur in fmw.conf !!!)
> 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.
I don't think this is all that much of a problem...
-- Ramon
