Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ JOSArchitectureDiscussion ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

PlatformAPIPages

We need to break up the JOS architecture into small slivers to deal out to everyone. Right now, we have a general architectural overview, which needs to be refined and inspected with an electron-scanning microscope.

This will require us to maintain the various architecture subpages to keep them up-to-date with the current design. This means comments can and probably should be cleaned up on occation as they no longer apply.

To start the discussion going, I'm going to quote from DigiGod, a message he posted 18 Nov 1999 to JOS and JOSArch mailing groups, then I'll follow up with my web-interpretation of his words. It was a rather long message, but I feel that it's well worth quoting in a more accesible place than the newsgroups:

In the more recent threads here I have noticed some confusion about the seperation of the elements of JOS, so I am going to attempt to clarify these here.

JOS is not like its predecessors, it is not one large monolithic clump-o'-OS. First we have JOSCore, this is the minimal OS consisting of a JOSBox and a minimal JOSystem and no more. Then we have "JOSExtensions" the devices, drivers and services it takes to be able to use JOS for more then the RAM equivalent of a paperweight. Running on top of this is the "Application Level" most notably JADE and its PUI (allowing the computer to interact with the user). This is all suspended in the lime Jell-O that is the Java and JOS API's (I think we should discriminate between JOS API's that require JOS and those that don't, I propose that the ones that do not require JOS be reffered to as the JOS Extra API's -- someone give that a better name...).

An Install/Uninstall library is an excellent idea, although it is not part of JOSystem it is a JOS Extra API (I hate to seem like I'm picking on it. I'm not, it's just the first instance I thought of...). Furthermore, JOSystem is -- basically -- just a pure java kernel (it takes on the classic role of the kernel in most senses and buffers between everyone and the real kernel in the other cases) and an appplication runner.

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. A JOSBox application could be made sans kernel, this is how you could run JOS on a non-JOS machine; the JOSystem would require extra features the JOSBox supplies to run so just running it on "any old VM" would be painful, a special JOSBox would be the way to go. The main benifit of this I see is not in having a showcase for JOS but in having a multi-process java environment running on ones computer, allowing (with minor modification) to let the OS "launch" Java apps into this environment/quasiOS cutting down on memory and start time (people would get to tour JOS then get to keep a powerful tool like that). I think we should get a kernel/VM JOSBox up then modify it to be an "emulator" JOSBox later on, just my opinion though.

JVM incompatabilities might be solved with the exokernel design. Exokernel is basically a blank slate of a kernel that allows libraries to be plugged into it to provide optimal hardware use (and, of course, having a default library for legacy apps). Whats this have to do with JVM's!? Good question, say we have most of the stuff that makes a JVM and then have little libraries filling the rest in, in a release compatiable manner. That is, we have XVM (exo-VM) with a JDK 1.0 library, a 1.1 lib and a 1.2 lib. I don't know how well that would work, but its worth a thought.

--DigiGod

To me, the architecture becomes (from bottom to top):

JOSCore JOSBox Kernel (native) JVM (native) JOSystem

JOSExtensions

ApplicationLevel

Where:

• JOSCore - the minimal OS, consisting of:
  • JOSBox - The "virtual computer" JOSystem is running on.
  • JOSystem - The bare minimal
  • No more
• JOSExtensions - the devices, drivers and services it takes to be able to use JOS for more then the RAM equivalent of a paperweight
• ApplicationLevel - most notably JADE and its PUI (allowing the computer to interact with the user)

See also [ JOSystem ] [ JOSBox ] [ PlatformAPIPages ] [ JOSCore ]

The general architecture of JOS should explain how the major pieces of the operating system fit together. It is the mission of these pages to search for that architecture and explain it. As soon as we figure out how these thing work, we can implement the architecture in code.

As you can see, the kernel and a virtual machine are two separate pieces. There might be more than one virtual machine that runs on a given kernel. For Java programmers, the relationship and responsibilities of these pieces might be explained in Java-like pseudo code. See also JOSArchitectureInJava.

How do we get there? We build a kernel. We build a JVM. We build another JVM. Then, we can figure out how you might build more than one JVM for a kernel. A interface between a JVM and its kernel is difficult to anticipate. It will mature as we go. -- GilbertHerschberger (19 November 1999).

Based on the discussions about JOSBoxModule and JOSKernelModule, the above (rather large and unsightly) table/model needs to be updated.

Here's my latest go at it. I've tried to separate the levels, so that all native code is in one area, and all bytecodes are in the next level:

Native
JOSCore JOSBox Kernel Module Interface	JOSKernelModule JOSKernelModule ...
Bytecode
JOSystem JOSExtensions ApplicationLevel

In this way, the JOSKernelModules are separate from the Core, yet are between the Extentions and the Core. The modules are still native, but are not used by

-- MattAlbrecht - 06 Dec 1999

Matt, your diagram clearly illustrates the machine code vs. bytecode. I like that. From your diagram and a diagram in JosPlatform, I put together the most comprehensive (for me) diagram I can think of. This diagram illustrates machine code vs. native interface vs. bytecode.

Here is yet another diagram of the JOS platform, based on the above diagram and other platform API pages.

This is only a dependency diagram. JOSCore and JOSExtensions are missing because they are related to distribution, not dependency.

This diagram illustrates an architecture with a place for everything I can imagine. It has strong support for bytecode from past, present and future Java Platforms. It enables us to create a mostly bytecode operating system. It includes a place for custom machine code when its absolutely necessary.

This diagram shows that custom class libraries are written in pure bytecode. When a custom class library needs additional machine code support, it must use a native interface to invoke machine code written in a kernel module. -- GilbertHerschberger (8 December 1999).

Not only are there many virtual machines for one kernel, there are many kernels for a virtual machine. The decaf virtual machine is designed to work with any "kernel", any object that extends the kernel class. When it is written to usea platform-independent kernel class, decaf runs unchanged on host and i386 builds of the JJOS kernel.

When writing a custom C/C++ program to test a kernel function, your test program must implement a decaf-like interface. Strictly speaking of course, a kernel is not required to run a virtual machine. -- GilbertHerschberger (7 March 2000).

Content of these pages are owned and copyrighted by the poster.
Hosted by: