Ulrich Weigand 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 ...
Okay, I'm convinced.
> But basically, it's just that exporting global variables is IMHO
> somewhat ugly, especially because you can't easily change the behaviour
> later on ...
As somebody mentioned earlier, macros may be the
solution.
> > > - perform guest debugging (set single step etc.)
> >
> > Why ? single step only involves asserting the trap flag...
>
> For now, yes. But strictly speaking, this is a violation of
> guest/monitor separation: the guest context should really contain
> the flags as seen by the *guest*. We don't really want to set
> the trap flag as seen by the guest, we want to set the *monitor*
> trap flag. (Imagine using ICE to single-step through a single-stepping
> guest debugger invocation ...)
What's the problem ? They both set TF, so it'll first trap
to the ICE and then to the guest debugger. Only need to
watch out the the interrupt is relayed on correctly. Though
that may be better taken care of by the kernel-level monitor...
So okay, we could make this an ioctl call. But then, I guess
you'd need to provide a similar system for breakpoints and
such... the problem is that a breakpoint interface would
be unusable by remote GDB, without weird hacks.
> > > - 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.
Well, I don't associate these with the GUI...
powerdown, reboot etc. are processor actions.
The GUI just calls them.
-- Ramon
