Ulrich Weigand 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 ...
Okay. I usually think of diffs more as "a way to update
my code without having to think about it" ;)
> [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 ...
Well, I'm NOT planning to do that. That's an awful lot
of work... :-/
I guess I should write a PERL script to do it ;)
> [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 ...
Whoopsie...
> > - 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 --
Yes I know, but my idea was to get it to work with bochs
as it is, for now, witout changing the framework. This
is just temporary anyway as we should really split up
the bochs plugin into multiple plugins, one per device.
> > 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') ...
Ok. Good.
> > 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 ...
Can you do that ? Or should I prepare another patch ?
> > 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
Okay.
> - nexus space is precious, so use it sparingly (i.e. use a bitmap
> of 256 *bits*, not 256 bytes) ;-)
Yes, that is one of the reasons why I posted the question ---
I wasn't sure whether we could miss the space or not ;).
I guess 32 bytes is not so much, but still...
> 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 ;-)
Okay, I'll do that.
-- Ramon
