>> 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.
Hmmm... I did some work on a Z80 emulator that involved something like this
a while back. The 'plugins' weren't actually separately compiled modules,
but I just did it so that the system was clear. Yeah, I'd say having such
a set of callbacks would be ideal. The callback should of course be told
what I/O address is being used, so that the same function can be used with
multiple hardware devices. Also, passing some kind of plug-in defined
'handle' around (maybe a void *), would probably be useful for further
abstraction.
Once this works, it'll make the writing of new hardware emulators much
easier, and I would recommend the creation of an explanatory document about
the interface, and a 'contrib' directory on an ftp server where people can
upload any modules they happen to write. I guess that this would probably
take off fairly quickly, once useful things can actually be done (like
running a linux kernel under the vm), as everyone would want their hardware
supported.
>> 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.
Indeed; as I pointed out in a previous e-mail, while GDB is great for
working with source code, it is not a very good debugger for working with
assembly language, which is what I intend to work on (as soon as I have
hardware that'll allow me to actually run the vm...)
>> 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.
Good plan; you could have an X-GUI, an svga gui, a text gui (!) for running
over telnet sessions (if you have a guest system to run that doesn't
require graphics).
>> 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...
If the plugins are linked to a single object, then I think the library
loader should be able to extract a single plugin out of a '.a' file, so you
would only have to lug two files around with you. Can't be that much of a
problem!
