Hi;
"Todd L. Miller" wrote:
>
> > I sent a message to the list earlier today asking whether I should
>
> [...] Of course, I read this AFTER asking...
>
> > (1) The "static variables" are exactly which ones? We shouldn't have
> > any static variables that require initialization code to be run -- given
> > the limitations of the current initialization code, it *won't* be run
> > for the i386 target.
>
> Er, the JAVA /class/-static variables in "jos.system.interrupts",
> name intXXX, from 001 to 015. Sorry for any confusion. You (next
> paragraph) disabled all the interrupts and then turned them back on for
> the java code to play with, which is the Right Thing to do; we just punted
> on what to do with the clock interrupt back when we were doing that part
> of the design. (Say! That means we've made it pretty far downfield.:))
OK. Do you think it's better to leave interrupts entirely *disabled* until the
Java code decides it's the time to enable them? This is an entirely reasonable
approach, and (hmm....) I don't think it will break anything at all (hmm...,
right?). Actually, I don't understand why I didn't do it that way in the first
place (maybe I'm forgetting something ... wouldn't be the first time).
> > Let me know what the status of your i386 build is, so I can tell whether
> > I'm either degrading things terribly, or the new changes are no-ops.
> > Like I said, I'm sitting on a whole bunch of changes...
>
> If I've got FN_TRACE turned on and all the VM tests running, it
> dies after the first keystroke in the consoled; haven't tested the new VGA
> driver at all; if I turn off FN_TRACE and all the VM tests, it runs long
> enough that I can confirm the various console driver changes I've been
> making; I've not crashed it yet there. (Though now that I think about it,
> FN_TRACE shouldn't have any effect on how long things run and I've not
> bothered to see if it actually does...)
So, in other words, I would not be breaking an entirely "working" build for
you...
> If you're sitting on a whole bunch of changes, it'll probably be
> easier for me to committ my stuff first. (Not much, yet, unfortunately.)
OK. Let me know when you do this ... I won't really be able to do much more
until Thursday at the earliest. Do you think you'll be able to commit your
stuff by then? I'd REALLY like to commit the changes both because I'd like to
attack some of the other remaining problems, and because I'd like the sources on
more than one disk for safety's sake.
> Oh, given that some of the corrections JM & Bocek made were to
> math ops that /should/ have been checked before this, if anyone feels like
> writing up a more comprehensive suite of test for init.java, do, with my
> encouragement.
Isn't there a JVM compatibility/test suite around? I can't remember the name,
but I seem to recall reading about it (but I seem also to recall some
licensing/NDA issues). Anybody else heard about something like this?
-jm
--
==== John Morrison ==== MaK Technologies, Inc.
==== Chief Technology Officer ==== 185 Alewife Brook Pkwy, Cambridge, MA 02138
==== [EMAIL PROTECTED] ==== http://www.mak.com/
==== vox:617-876-8085 x115 ==== fax:617-876-9208
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
