> I've added support for atomic operations, debugging, interrupts,
> inter thread communication, time, timer, virtual memory. And updated
> io ports, linear memory, monitors, threads, and data types.
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 made this update so I can get more input on what changes need to be
> made, and so the interface is mostly defined before I start working
> on a jos-linux host.
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, 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.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
