AStartingPoint.Imported @ jos.sf.net

Flamebait: I propose that, at least to start with, we use the Linux kernel. Although it is implemented almost entirely in C, and is more old technology than new, it's a stable starting point which gives a mass of device support free. When we feel comfortable, we can then hack the kernel down to our (more modest) requirements and convert most of what we need beyond that to java.

Comments?

I believe people are already working on the kernel, so this is probably a moot point. If we were to use Linux, I know I've seem someplace a Linux kernel that fit on a floppy... --BillRehm

Are people actually hacking on the kernel? If so, great. --Ben

I'm interested in seeing a well-defined and comprehensive system level services API. Once this is defined and used and "made robust" through test usage, an implementation could, for example, sit on top of fsf GNU HURD/ microkernel.

The Gnu HURD idea seams very object oriented/ partitioned/ service provider/ consumer pattern etc, etc. (Read about it at http://www.fsf.org/ ). The Gnu Mach microkernel I think is now "self hosting" - ie. it is rapidly coming to a usable/stable point. The servers that run on top of the microkernel (the HURD) seem to fit right in with the JOS concepts.

I think that the main requirement for actual development will be a Java compiler, and Cygnus Solutions is producing a Java front end layer for gcc (the Gnu C++ compiler) - it will be GPL I believe. This suggests that using Gnu/Linux or Gnu/HURD would be a convenient starting place.

Ultimately, the kernel of any OS will require to be fully machine compiled for performance (for things like graphics rendering). Perhaps the question to ask is "does the latest Mach microkernel represent the best design of a kernel?" If so, then just use Gnu Mach microkernel (perhaps re-write it in Java). If not, then a new design would be needed - however I think that many many minds have been put to this very task and that the Mach microkernel represents the very latest and best ideas in an actual implementation. If so, there is probably no great need to rewrite it in Java (unless perhaps porting it to a new hardware platform). -ZenaanHarkness

Question: How does one write a device driver in Java??? -ZenaanHarkness

While checking up the Hurd's progress at fsf.org (as per above), I found to my surprise that they've got a running system on it. Linking around a bit more brought me to the MkLinux project at OSF, which is quite interesting in and of itself, and ... an ongoing project to build a Java VM ontop of a MachMK to support running Java apps on low end hardware. They even start at one floppy! No binaries are available on the page, which is quite out of date (March 97), as was the MkLinux page (April 97), but they seem to be making great strides towards eliminating the Unix dependencies of the VM. To quote: "The process now consists in eliminating UNIX dependent I/O system calls one after another. "

Link: http://www.camb.opengroup.org/RI/java/jlite/index.htm

Have at!

If you want an uptodate microkernel and don't want to write it from scratch, I suggest to have a look at L4. http://os.inf.tu-dresden.de/L4/ I don´t know if they have overcome a licensing problem. If so, thats a minimal os-kernel. As it is able to act as a linux kernel it may be a useful base for jos. --WernerMetterhausen

We should not forget though, that a Java based OS ( or VirtualMachine based OSes in general) need less of a kernel than "standard" OSes. StephenEarly creates a small and minimal kernel which will allow us to port Kaffe to for a start. It is expected to be finished very soon. This does not exclude the possibility that we could also port JOS as a personality to e.g. GNU Hurd, though.

-MarkusPeter

has anyone looked at the flux oskit? they've already build a javaos prototype, by linking kaffe and the oskit. both are free software, though the oskit is currently not available while the next release is prepared (though you can ask for a copy of the previous release, if you have a good reason to need it.

http://www.cs.utah.edu/projects/flux/oskit

rjones@pobox.com

The starting point for the OS should be a µ-kernel like the L4 µ-kernel ( http://os.inf.tu-dresden.de/pubs/sosp97/ ).

Design of the L4 µ-kernel: "The L4 µ-kernel is based on two basic concepts, threads and address spaces. A thread is an activity executing inside an address space. Cross-address-space communication, also called inter-process communication (IPC), is one of the most fundamental µ-kernel mechanisms. Other forms of communication, such as remote procedure call (RPC) and controlled thread migration between address spaces, can be constructed from the IPC primitive."

Platforms of the L4 µ-kernel: The L4 µ-kernel was "Originally developed for the 486 and Pentium architecture, experimental L4 implementations now exist for Digital's Alpha 21164 and MIPS R4600."

Objects can be implemented as basic unit of processing as active objects, as a address space with one or more threads, in the µ-kernel. Small object can for performace reasons be implementet as passiv objects, which life only inside a address space and may not be referenced by different active objects. This design enables the migration of active objects which is important for dynamic load balanceing, agent based processing, ... .

Address spaces can be implemented as persistent memory by user-level servers outside the µ-kernel. The MATISSE database system ( http://www.adb.com )can be a good starting point.

kloehner@csc.com

Matisse is a commercial product, isn't it? How do you propose we use it as the basis for presistent storage in a Free OS with a GNU-style license? --BillRehm

Anybody ever considered the GNU gcc compiler for JOS?
Read more & react at: GCCconsiderations
-- ChristianSchnell 1998/01/13

I updated that topic.
-- ChristianSchnell 1998/01/15

You'd be speaking of the ongoing work to add java to the list of languages that gcc/egcs can handle, and you'd obviously know more than I do about that. We can certainly use gcc/j or egcs/j for compiling parts of the system, but the compiler we ship will have to be a classfile, not a native program. This sounds like a VM/pkernel kind of thing, unless RMS is planning to start porting GNU apps to java. Any kernel hackers reading this page?

I found this message in comp.lang.java.advocacy:

  It is possible to write an OS completely in Java,
  just imagine writing java code that produces the
  correct machine code to access the underlying
  hardware, not incredibly far fetched. Then imagine
  writing an OS in Java on Machine A that already
  supports Java, as a part of the OS, completely
  written in Java, it can compile itself to run
  on Machine B, that does not support Java. If
  nothing is written in C, then I call this an
  OS written in 100% Java. Of course it is also
  a compiler, but then, we are stepping up to
  the next generation of Operating systems
  that must know about compilation (ala Merced).
 
  Nothing prevents Java from "knowing" about
  interfacing with the underlying hardware,
  there is just no traditional way of doing
  when thinking in the non dynamic programming
  language context.
 
  Sean

Sound interesting. Can we write a kernel that compile itself for any platform?

-- paolo@squareusa.com 1998/02/03

No. It's not possible, no matter which programming language. Each platform has its own specifics, and you have to do at least a porting of the platform-dependant code to the new platform.. Even if you create a 100% portable kernel in Java, then still the compiler would have to know about the specifics of each platform.

Furthermore there are no good Java->native code compilers around which would be suitable for doing low-level stuff. We can be lucky that finally the first Java->native code compilers for the application level are around ;-)

Having the kernel written in Java would maybe be a nice long-term goal, but surely no starting point for creating an OS.

MarkusPeter

I tend to agree... There has to be some level of communication to hardware. Some it will be platform (or at least processor) dependent. I have written up a basic idea for device drivers and memory management that deals with the hardware side of things. It isn't complete, but it's worth talking about. See KeithsDriverDesign for the info.

-- KeithMason 16-Mar-1998

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