PlatformAPIPages; JOSArchitectureDiscussion
For Java programmers, the architecture of JOS might be a little easier to understand by using Java-like pseudocode. These are not real Java classes. Instead, they illustrate the relationship between the kernel, Java virtual machine and JOSKernelModule.
These are not a run-time pictures; but a picture of class inheritence.
A module is a native code plug-in for a kernel. The kernel must discover the native methods of a module, just like an application (like a classic Java virtual machine) discovers methods in a shared library.
public interface Module {
public void init();
public void destroy();
public String[] listMethodName();
public * getEntryPoint( String methodName );
:
}
All of the JVMs must implement similar methods in order to be useful to a kernel.
public interface VirtualMachine {
:
}
Many implementations of a virtual machine are possible. Only one is required.
public class BasicVirtualMachine
implements VirtualMachine {
:
}
public class SmallVirtualMachine
implements VirtualMachine {
:
}
public class FastVirtualMachine
implements VirtualMachine {
:
}
When you combine a Module and VirtualMachine, you get a plug-in module for the kernel that happens to be a virtual machine.
public class BasicVirtualMachineModule
implements Module, VirtualMachine {
:
}
A kernel uses modules and a virtual machine.
public interface Kernel {
public void init(...);
protected VirtualMachine getVirtualMachine();
public Module createModule(...);
public Enumeration getModules();
:
}
There might be many implementations of a kernel. Only one is required.
public class BasicKernel
implements Kernel {
public native void init();
public native VirtualMachine createVirtualMachine(...);
public native Enumeration getVirtualMachines();
public native Module createModule(...);
public native Enumeration getModules();
:
}
The JOS architecture has other relationships. Could these be expressed in Java-like pseudocode, too? I would like to think so.