Hello Todd
> Seems to me like the kernel shouldn't be involved in monitors,
> unless you plan to have it support multiple native processes --
> and then the katomic operations would seem to suffice for
> implementing monitors inside the JVM -- where they belong.
I can see what you mean. But I don't think I will remove it.
How I see the kernel interface being used by a jvm developer. Is
that the developer will wrap the kernel interface function call into
a jvm function, with added validation, error checking, debugging,
etc. The jvm developer is free to write there own version of a
function, as long as it is done in a way that won't cause problems
with other kernels, etc.
> How will your jos-linux host differ substantially from the 'host'
> build of JJOS? (From the p.o.v. of decaf, the JVM.) Or were you
> thinking more broadly, along the lines of kludging something
> together out of other open source projects
> (linux/kaffe/classpath/etc) and write wrappers to this proposed
> standard?
I don't think there will be much difference, both would be used as a
development aid, for testing the jvm, class libraries, etc.
I'm planing on using a linux system to provided the base kernel,
Japhar as the jvm and maybe using classpath for the class libraries
(but I don't know yet).
> I, at least (can't speak for JM), will probably not spend any time
> rewriting decaf/JJOS to match any standard we settle on any time
> soon, for the twin reasons of speed and efficiency. Speed in
> development has been our goal -- with the end result that I expect
> the keyboard driver (more importantly, the scancode-to-unicode
> converter) to be fully functional before the end of june.
> Efficiency stems from my concerns about trying to set an interface
> for something that (I would guess) none of us have ever done --
> (build) a new kernel. From my point of view (admittedly, I'm not
> writing the kernel half of things) it would make sense to wait
> until JJOS matured to the point where it wasn't going to be
> changing a whole lot anyway, and /then/ settle on a design,
> applying both our experience in what a kernel needs to do and our
> desires for improvements; refactoring by way of /educated/
> interface design decisions. This as opposed to continually
> rewriting the interface as new factors came out.
Although I haven't look into JJOS/decaf very much, how I would port
JJOS/decaf to use the kernel interface, is to write a version of JJOS
that uses the kernel interface internally. I don't know how hard
that would be, but it should be possible.
Robert Fitzsimons
[EMAIL PROTECTED]
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
