bigwizard_small.png I am, therefore I design code. Sometimes I write code too.

I have various projects, including (but not limited to) a programming language, and an operating system.

One can reach me in the Mega-Tokyo forums, or send me email at tvoipio@cc.hut.fi. I also have currently somewhat out of date web page.

My OSProject: µNeon

This is currently the "official" µNeon web presence. I will migrate it to a real server at some point.

The reason I'm putting this here now, is that local target audience, is also my target audience.

Latest public µNeon "release" can be found at http://www.cs.hut.fi/~tvoipio/files/neon/.

Data:

µNeon goals:

In short, try to combine simplicity, security, and freedom.

System:

My approach is pretty prototypical example of Eleanore Semaphore.

Current µNeon design is based on an asynchronous message passing microkernel design, which allows the above quite naturally. Many system services can work in exactly the same way whether inside or outside kernel. At present those run outside for some extra safety and flexibility (easier to update or restart on the fly, for example).

Rest of the system (and parts of the kernel too) are structured as objects sending each other messages. There is a tool called 'nifgen' that serves the purpose of interface generator, but it really does the absolutely minimum: generates hash-codes for interfaces and interface methods, and adds a few bits of type information into those, so that system messaging can figure out what kinds of message needs to be copied.

Currently two types are supported: pulses (just two immediates), and full messages (specified as user pointer and length). Full messages have a fixed maximum length (currently 1024 bytes). All messages can also transfer one handle. Handles are used to specify the target of the message, and are both secure and opaque: they can't be forged, but just by holding a handle it's impossible to tell who implements the service the handle names. This also hold the other way: a service will only know which handle was used to access it, never who holds the handle.

Alternative method of communication is using shared memory, which is rather involved, because any object can act as memory provider, but doesn't require the memory user to trust the memory provider. Because of this, page fault handling is somewhat...funny. From application programmers point of view it is quite straightforward, though.

As a whole, I'm currently very happy with the system, with the hardest problems mostly solved (properly).

Finally, in the future a set of high priority threads can hopefully run as if they where running on an RTOS, since there isn't really any non-constant-time non-preemption-safe code in the kernel, even if the kernel currently runs much of the time interrupts disabled.

For more complete description of various system services and their design history, search forums for 'neon'.

Status:

The microkernel is practically finished. The only thing missing from kernel is support for process-to-process memory mappings, and some process control interfaces.

Development is shifting outside the kernel, mainly into base system services and drivers. Following have priority (in no particular order):

Next release is scheduled when I consider the kernel "good enough for now", which is hopefully this summer 2006. No promises though.

Other OS related stuff:

I've also written a (concept level) virtual memory tutorial, which is at http://www.cs.hut.fi/~tvoipio/memtutor.html, and a synchronization minitutorial (both kernel and userlevel) which is at http://www.cs.hut.fi/~tvoipio/threads.html.

Maybe those are useful?

Comments:

You are welcomed to leave your comments below.