Indian Developers Redesigning Linux Kernel With OOP, C++ Support

[Luke_Wolf]

So they make sure at compile time that no process can access the memory of any other. Including their so called kernel? That excludes usefull techniques like zero-copy and shared memory. I'm prety sure, at least for some workloads, having to copy things around would do more harm then saving a few syscalls.

Yes, no process can deal with the memory of another, instead it uses type safety and code contracts to perform efficient IPC, and based on this research paper http://research.microsoft.com/apps/pubs/?id=69431 they do seem to have figured out a way to do zero copy with the IPC because of the type safety and code contracts.

[WorBlux]

Actually VMed languages are really interesting for microkernel based designs, because this allows you to rely on software memory protection instead of hardware and thus allows you to avoid the context switch between user-space and kernel-space, which means that a VMed language microkernel design could in principle actually run faster than one that is not written in a VMed language

Interesting, though my thought here is that a microkernel should be small enough to embed on an ASIC. If the kernelspace is embedded in the hardware shouldn't these switches be avoided as well? Even if this is in far left field I'm thinking there's space in hardware design to address the problem.

[WorBlux]

Why not Rust? The API isn't stable yet, but it will be soon.

It seems fairly close in philosophy to D to me, seems like it could be suitable as far as I can tell.

[Guest]

actually it has, kmalloc
it's still not that simple, the memory management
another fun fact it that there are 3 types of pointers used in the linux kernel
more on that in http://lwn.net/Kernel/LDD3/

funny thing that OOP is not a well defined term at all

Im well aware, my main point was that you can't take D/Haskell/etc compiler and simply generate 'user space like' code constructs in kernel.
Also, kmalloc doesn't really work as drop in replacement for malloc.

While it would be possible to use _some_ C++ OOP features in kernel, many would not work (without serious changes to Linux codebase).

I think that FAQ on linux.org sums up all the reasons quite nicely (albeit it was written like a decade ago).

[Guest]

forgot to say
malloc() is a libc function anyway
it uses mmap() and some times break() to get memory

You probably meant brk, break is a keyword in C.

[gens]

You probably meant brk, break is a keyword in C.

y, didn't use it in a while
just to mmap is better

[longwest]

One of stupidest things I ever read.
Run kernel on Java or C#? WTF you were smoking?
What about VMs those 2 languages need to run?
One by Oracle and another one by MS.
Should we embed jre + mono into kernel to run modules?
Or should we run kernel modules with userspace runtimes?

[sarcasm] Excellent idea for the linux kernel. [/sarcasm]

Internet has made it very clear.

[Svartalf]

Why not Rust? The API isn't stable yet, but it will be soon.

You precisely give the reason why NOT Rust. If the API isn't mostly set in stone for the first true iteration of the framework and language- it's not sound practice to use it in a Kernel except as a research project.

[Svartalf]

I think that FAQ on linux.org sums up all the reasons quite nicely (albeit it was written like a decade ago).

Even if it's a decade ago, if you've not got the bits and bobs there to make it happen now, it's no different from then.

[Hamish Wilson]

Even if it's a decade ago, if you've not got the bits and bobs there to make it happen now, it's no different from then.

Sorry for posting something so off topic everyone, but I would like to contact Svartalf regarding a professional matter but his PM inbox on Phoronix is full. I am hoping that he will be notified by email of my reply to his post so that he can make some space free. I have a very viable porting opportunity I would like to discuss with him.