| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
A JOSBox is part of JOSystem. It is critical to the success of the JOS Project. The time has come to gather together more information about this layer of the JOS architecture and its impact on the performance of a JOS JVM.
The JOSBox would start and load JOSCore... - DigiGod [3]
In other words, the first bytecode interpreted by a JOSBox must be stored inside JOSCore. When written in machine code on a foreign processor, the JOSBox is loaded and started by a boot loader. It contains a kernel and JVM. The JVM interprets bytecode, starting with the init class stored in JOSCore. The init class performs a similar start up sequence on every implementation of JOSBox. Through custom configuration and JVMSpecificClasses, a JOSBox can perform any data processing function.
From the start up sequence, a JOSBox must be initialized first and then the JOSBox starts JOSCore. Here is the start-up sequence from the bottom up.
| boot loader | ||
JOSBox
|
||
| JOSCore |
By keeping JOSBox separate from the kernel and VirtualMachine, we can build one JOSCore that runs on many implementations of JOSBox. While there is only one implemenation of JOSCore, there are many implementation of JOSBox.
When a class in JOSCore uses a native method, that method is part of the native method API between JOSCore and any JOSBox. While it is not required for JOS to use the JavaNativeInterface as the mechanism for JOSCore to call JOSBox, something like the Java Native Interface is required. Something must be invented to cross the barrier between Java code and its native methods.
Pure bytecode application will run on JOS. A custom package must use JOSCore to implement what might otherwise be implemented in a shared library. Sorry, but your typical shared (or dynamic link) library will not run on JOS. It must be recompiled to meet the requirements of the JOSBox. The format of shared libraries, calling convention and many other details are yet to be discovered. -- GilbertHerschberger (17 November 1999)
From a traditional OS standpoint, DeviceDrivers need to have some place where they can be referenced from, and where they are discovered. Drivers are not part of JOSBox, nor are they part of JOSCore, yet they are used by JOSCore to help implement the java. and javax. packages.
The JavaOS for Business documents describe in detail the device discovery and usage mechanisms. Discovery of devices does not belong in the above diagram, as the diagram describes how the APIs build upon one another, whereas the discovery is a process performed by an API layer. The devices operate in a layer within the JOSBox (according to our model), since they use both native and Java code.
The discussion of DeviceDrivers may seem out of place here, but they are critical to the operation of the OS. Where they stand in relation to the packages which use them, and which the drivers depend on, is one of the architecture's foundation.
-- MattAlbrecht - 17 Nov 1999
The JOSBox is the computer were writing this OS for, in a sense. It is the virtual hardware the JOSystem "kernel" is running on, if someone made this into real hardware a modified JOSystem would run JOS on it directly. It is the true kernel and the JVM. -- DigiGod
The JOSBox is an abstraction of hardware. It is the low-level stuff that must be written with native code. It is limited to computer processors and I/O chips on the processor bus. It deals with RAM, hardware interrupts, and DMA channels.
The JOSBox isn't the high level operating system stuff you might have grown accustomed to. It uses very few of high level concepts. It does not contain a driver for your favorite printer. It doesn't even contain a driver for a printer device. Rather, it contains the lowest level mechanism of writing a byte to any port, reading a byte from any port, initializing a port and checking on low level port status. -- GilbertHerschberger (17 November 1999)
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|