OSDev.org

Sometimes you reinvent the wheel because you can make it rounder, or because you learn from it. I agree a new framework would break compatibility, but sometimes that's for a greater good =). If I ever create a framework, I would rather start a new one and develop some wrappers. This gives me the possibility to try innovations, and to learn how to implement other frameworks (and how they work and map to these new ideas), while at the same time I don't break compatibility. Just .02 cents,

JVFF

Agreed -- an operating system built on this design isn't going to maintain compatibility with existing applications. It's too radically different in many regards. Compatibility layers can be built on top of it, perhaps, but generally these will turn out to be virtual machines... so compatibility with a virtual machine isn't necessarily a priority!

Anyway, I'm working on such a system, although singularity wasn't my inspiration - I first heard about this concept in connection with JX, a system based on Java. My system is somewhat different:

* My language is a subset of C and/or C++. Other languages supported by GCC could also be used with only a little extra work.
* I'm using LLVM as the intermediate representation. LLVM isn't typesafe or memory safe by default, so I'm having to implement extensions to allow it to be, which is turning out to be hard work.
* I haven't done any proofs yet, but I don't see the big deal in preventing additional modules being loaded into a running program. Yes, you have to do a type-safety proof per module permutation, but in most cases modules will be loaded in the same order on each run, so you only have to do it once, after installation.
* I haven't seen any systems of this kind that don't use garbage collection (and, I'm afraid, reference counting is just a form of garbage collection, it might work differently but it has its own drawbacks). Garbage collection and real-time systems are mostly incompatible, which I consider unacceptable. I plan to attack this problem using the approach developed by the Safecode project, which allocates each object its own page in the page table (although they still share a physical memory page) so that when the object is deleted and its memory reused, its page can be deallocated and any reference to the dead object can be caught. Unfortunately, this uses up PTEs pretty quickly, so a 64-bit processor is a must, really.

Anyway, anyone thinking of taking this approach should be reading this paper, which is a summary of the original ideas behind the movement, and what it hopes to achieve.

http://www.cs.cmu.edu/~rwh/papers/langsec/dagstuhl.pdf

What I hope to achieve is a C++ microkernel that can perform IPC in not a lot more time than a C++ method call takes.

[quote=ntfs]Not processes but domains. The processes are classic microkernel approach, that means there is some client and server each of them running it's own thread. But domains can share the threads (you are aible to call A domain's function foo from domain B in single thread) [/quote]

My design is to use processes with an RPC-like IPC format. For process A to communicate syncrhonously with process B, what happens is this:

Process B creates an object where it registers a method to be called when a request is received. B's thread 1 calls or similar. Thread B1 is suspended.

Process A thread 1 invokes a method on an object that calls to B's portal. Thread A1's ownership is transferred to B. This involves reading and writing a single cache line of memory.

B does some calculations in A1 and returns. Thread A1's ownership is transferred back to A. The same cache line as above is updated again. If the IPC is simple, it's probably still in cache. Otherwise, the performance issues of an extra memory read/write cycle are irrelevant. Once this is done, thread B1 is released, allowing B to perform cleanup operations in its own context.

A variant exists where thread B1 terminates, and is never used again. This variant allows multiple threads to execute in B's context with lots of different requests, whereas the former only allows a single request thread. In this latter variant, B would probably use a semaphore to limit the number of active threads working in its context at one time.

The advantage of this scheme compared to allowing direct execution of B's code is that it allows easier tracking of ownership of memory. New memory allocated by A1 while executing B's code is assigned to process B. That memory can then be safely returned to the system when B exits.

How to handle memory shared between multiple processes is an aspect of the design I'm still working on. An absolute requirement of my design is zero copy IPC, even for complex objects.

notice how important the Bartok compiler is to the Singularity project?

Reading the papers, i suddenly felt 'why dont we have such a strong free compiler?' [maybe there are, but what looks from the abilities of bartok, it is more advanced than any compiler i've used]

eg. these guys easily incorporated contracts into the language, which btw is a totally new construct, and also they have so called linearity, which they use to ensure that object once passed through a channel wont be accessed in the sender code again. Apart from a DFA style verifier, they also have a static verifier. This kind of modification, in project like GCJ will take months, maybe years.

They're being done in C++ right now? IIRC conceptgcc is like that, at least for c++, as per concepts etc.