OSDev.org

Here's the point.
All kernels I have ever seen consist of a Hardware Abstraction Layer (with device drivers), and other concepts built on top on it. So I thought of a thing; once we have all those pieces, wouldn't it be better to code the kernel itself using a custom language that would be platform-independant (using a bitcode system such as Java's one) but interoperable with other languages such as C. The basic idea is that we would write platform-dependant thing in classic languages such as C, but generic things (such as scheduling algorithm, task management, logical device coordination...) in a platform-independant language that would just allow us to organize the kernel, while calling the C routines for everything that is actually platform-specific. This would allow us to port our kernels to other architectures by just rewriting a bitcode compiler and all those platform-specific things, but the kernel would work just fine without a single code change.

I searched Google, and found a similar project at Microsoft Research, called Pebble, and even though I don't like Microsoft so much, I'm glad to know that there are professionnals thinking alike me. So do you think it would be worth it ?

With proper design, a C kernel and its drivers is mostly source-level architecture independent.

With strict interface enforcement (for passing abstract API pointers), a C binary driver might be OS-independent if the architecture is same, although it's of less interest for many people and greatly limit the flexibility.

Then, the usefulness of fully architecture independent binary-level portability, which you're talking about, is an open decision - but chances are that for different architecture the device might already be meaningless (you won't talk about PS2 controller on ARM).

AbstractYouShudNow wrote:This would allow us to port our kernels to other architectures by just rewriting a bitcode compiler and all those platform-specific things

Currently we only have to rewrite all those platform-specific things. Of course "a bitcode system" might be interesting if source code for these platform-independent modules are kept under wraps even from people who port the system for some other architecture. Might be a valid reason for big companies.

AbstractYouShudNow wrote:Here's the point.
All kernels I have ever seen consist of a Hardware Abstraction Layer (with device drivers), and other concepts built on top on it.

Count mine out. I don't have a HAL. I don't see the point for such a layer. Unless the user-API is the HAL.

Antti wrote:

AbstractYouShudNow wrote:This would allow us to port our kernels to other architectures by just rewriting a bitcode compiler and all those platform-specific things

Currently we only have to rewrite all those platform-specific things. Of course "a bitcode system" might be interesting if source code for these platform-independent modules are kept under wraps even from people who port the system for some other architecture. Might be a valid reason for big companies.

I think his idea is that you wouldn't have to even recompile anything but the bytecode compiler and the platform-specific stuff to do a port.

But recompiling isn't *that* hard.

linguofreak wrote:you wouldn't have to even recompile anything but the bytecode compiler and the platform-specific stuff to do a port.

So you effectively move the HAL to the bytecode compiler or its support library. There's still difference between device support on arches that only support MMIO (arm) and using port IO (x86).