Julian Hall wrote:
> >> 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.
plugin_t * ? (see user.h). Of course, the plugin currently
doesn't actually *know* this value, but that can be altered.
> >> 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!
The problem is that all plugin entry points need to have the same
symbol names, which creates conflicts if you try to link them
together. Currently, these are plugin_init() and plugin_fini().
A different idea would be to support .tar.gz archives of
plugins, like I've seen (for instance) netscape do with java
classfiles.
-- Ramon
