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

[gens]

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

[Luke_Wolf]

And they would also allow cooperative multitasking, all that preemtiveness adds way to much overhead!!!

Do you have any ideea what you are talking about?

http://en.wikipedia.org/wiki/Singularity_(operating_system)#Security_design

http://en.wikipedia.org/wiki/Language-based_system

[Ansla]

From the link you posted:

The hardware abstraction layer is written in C++ and runs in protected mode. There is also some C code to handle debugging.

So there is a microkernel written in C++ and the whatever# part is strictly userspace. And linux can do that as well to some extent. You can implement a filesystem in userspace using FUSE and you can do that in any language you like (for example python)
Also in python you can write drivers for any input device, or any usb device. There are also ways to interact with graphics cards or even arbitrary pcie devices through sysfs.

There is no such thing as a kernel written in a language that relies on a VM and there will never be unless the CPU is able to provide the underlying VM. I remember there was a project of SUN to make a CPU that runs Java bytecode natively, but I don't think they ever went so far a to implement the JRE in hardware.

[Luke_Wolf]

From the link you posted:

So there is a microkernel written in C++ and the whatever# part is strictly userspace. And linux can do that as well to some extent. You can implement a filesystem in userspace using FUSE and you can do that in any language you like (for example python)
Also in python you can write drivers for any input device, or any usb device. There are also ways to interact with graphics cards or even arbitrary pcie devices through sysfs.

There is no such thing as a kernel written in a language that relies on a VM and there will never be unless the CPU is able to provide the underlying VM. I remember there was a project of SUN to make a CPU that runs Java bytecode natively, but I don't think they ever went so far a to implement the JRE in hardware.

Read the full paragraph and try again

The lowest-level x86 interrupt dispatch code is written in assembly language and C. Once this code has done its job, it invokes the kernel, whose runtime and garbage collector are written in Sing# (an extended version of Spec#, itself an extension of C#) and runs in unprotected mode. The hardware abstraction layer is written in C++ and runs in protected mode. There is also some C code to handle debugging. The computer's BIOS is invoked during the 16-bit real mode bootstrap stage; once in 32-bit mode, Singularity never invokes the BIOS again, but invokes device drivers written in Sing#. During installation, Common Intermediate Language (CIL) opcodes are compiled into x86 opcodes using the Bartok compiler.

If you've got additional time watch this http://channel9.msdn.com/Shows/Going...nge-of-the-SIP
and otherwise look up Software Isolated Proccesses

[Ansla]

Maybe you don't understand what protected mode is. Like you said, whatever# runs in unprotected mode (aka userspace) while the C++ part runs in protected mode (aka kernelspace).

[Luke_Wolf]

Maybe you don't understand what protected mode is. Like you said, whatever# runs in unprotected mode (aka userspace) while the C++ part runs in protected mode (aka kernelspace).

I think our difference of opinion here is more one of semantics than of technicalities surrounding the definition of a kernel which is defined as:

the piece of software sitting between the hardware, and the system and user level software.

Which for me includes the HAL and the whatever# as the kernel, whereas you're wanting to cut it at what's running in ring0 because of interpreting the whatever# as a user/system process as opposed to part of the kernel, which isn't really a wrong interpretation of the definition, it's just a different interpretation than mine. That said I'm not going to argue this point particularly as it's just completely besides the point of what I'm getting at.

My point is that VMed languages allow you to have software isolated processes as opposed to relying on hardware based isolation which cuts down on the number of mode switches needed thus alleviating one of the more fundamental problems with microkernel designs.

[jayrulez]

There is no such thing as a kernel written in a language that relies on a VM and there will never be unless the CPU is able to provide the underlying VM.

Not true. MOSA which I highlighted earlier has a kernel written in C#.

[gens]

http://en.wikipedia.org/wiki/VM_%28operating_system%29

[Ansla]

I think our difference of opinion here is more one of semantics than of technicalities surrounding the definition of a kernel which is defined as:

the piece of software sitting between the hardware, and the system and user level software.

Which for me includes the HAL and the whatever# as the kernel, whereas you're wanting to cut it at what's running in ring0 because of interpreting the whatever# as a user/system process as opposed to part of the kernel, which isn't really a wrong interpretation of the definition, it's just a different interpretation than mine. That said I'm not going to argue this point particularly as it's just completely besides the point of what I'm getting at.

Have a look at L4Linux. In that case can you still consider Linux a kernel? Since the drivers have to be modified to not access the hardware directly but use the L4 api to do so I would say no. It's just a regular L4 application that hapens to share a lot of code with the kernel with the same name.

My point is that VMed languages allow you to have software isolated processes as opposed to relying on hardware based isolation which cuts down on the number of mode switches needed thus alleviating one of the more fundamental problems with microkernel designs.

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.

[jayrulez]

Have a look at L4Linux. In that case can you still consider Linux a kernel? Since the drivers have to be modified to not access the hardware directly but use the L4 api to do so I would say no. It's just a regular L4 application that hapens to share a lot of code with the kernel with the same name.

In this case, Linux is still a kernel. To the application running on L4Linux, nothing changes. It is transparently running on a (para)virtualized Linux kernel.