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.