Ramon van Handel wrote:
> - Josh's curses code (just the same, except that
> I *did* run autoconf ;)).
Please don't ;-) Think of the diff you are sending as
*human-readable* documentation of the change you are proposing,
not just something to be processed automatically ...
I do read the patches before applying, and it helps if they
don't contain huge amounts of irrelevant stuff like a re-generated
'configure' or lots of whitespace-only diff ;-/
[snip]
> Question --- does anybody have an idea how I can
> easily check whether any #included headers are
> unused ?
Remove all #include's and compile, then keep adding necessary
headers until all errors disappear? I don't know any easier way ...
[snip]
> also, changed edi to esi for outs, etc.)
Not everywhere, it seems ;-) I've fixed the same bug in the
regular (non-rep) outs case ...
> - Changed plugins/bochs/io.cc to correctly handle
> rep ins/outs in the bochs framework (Kevin, is
> this the right way ?)
Well, it would appear to work correctly, but this does of course not
yield all that much benefit -- the real solution would be to pass
the count down to the device-specific handlers, so that they can
speed up their operation (e.g. by reading a whole block of data
directly into the buffer, if a 'rep ins' is done on an IDE disk
data port ...)
Of course this would imply a re-working of the device drivers, so
it is not an immediate concern. The important thing for now is that
the count is passed down to the plugin at least, so that plugins
*can* perform that optimization if they want to.
> PS what are all the *.orig files ? Can these
> be removed ? Ulrich ?
In the main CVS tree are no .orig files. These must have gotten
into your working tree (presumably as result of running 'patch') ...
> Also, as far as I'm concerned, plugins/bochs/gui/macintosh.cc and all
> references to it can be removed.
That's fine with me ...
> I was thinking of adding interrupt interception
> to the kernel module. The way I envision of doing
> this is to create a bitmap for the interrupts, and
> to set a bit when an interrupt is allocated.
> raise_interrupt() would then check this bit and
> if set, it would forward the interrupt to the
> user monitor. Where should I put this bitmap ?
> In nexus_t ?
Yes. This array must be accessible from both host and monitor side,
so it must reside within the nexus. Please note that
- every change to nexus_t *must* be accompanied by the corresponding
change to the nexus global variables at the start of nexus.S
- nexus space is precious, so use it sparingly (i.e. use a bitmap
of 256 *bits*, not 256 bytes) ;-)
B.t.w. you probably want to add the test to emulate_int, not raise_interrupt,
because the latter is also called if the *host* side itself forces an
interrupt raised. As the interrupt interception might want to call the
guest interrupt handler after it has processed the interrupt itself,
you want to avoid having manually raised interrupts themselves intercepted ;-)
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
