At 12:33 AM 1/16/00 +0100, you wrote:
>
>Ramon von Handel wrote:
>
>> > - access guest memory and registers
>>
>> I think these should remain accessible directly. It's a lot
>> faster and easier, and I don't see any reason why not anyway.
>
>Well, we'll need to have support for guest paging and segmentation,
>which might be easier via routines. Then, we might want to support
>architectures like BeOS, where you can't mmap the guest physical
>memory anyway, because BeOS doesn't *have* mmap, so we could fall
>back to read/write calls instead ...
>
>But basically, it's just that exporting global variables is IMHO
>somewhat ugly, especially because you can't easily change the behaviour
>later on ...
One possibility would be to require memory to be accessed via macros defined
in the plugin.h or whatever plugins would use; this could combine the speed
of direct memory access with the flexibility of using function calls?
>> > - trigger global actions requested via the GUI
>>
>> Probably the GUI should be a separate plugin, that
>> has its own API towards the rest of the plugins.
>> Then, plugins can interface the GUI directly and
>> user.c/plugin.c have nothing to do with it.
>
>I was thinking about actions that originate with the GUI
>but have global impact, like shutting down if the user
>clicks the close box, or rebooting if the user clicks the
>reboot icon, etc. These commands will need to be signalled
>back to the main app.
I would also like to be able to do things like select the system to run,
etc, through the GUI as well as on the command line, or in the
configuration file.
