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

[phoronix]

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

Meet BOSSMOOL, an effort to redesign the Linux kernel by adding object oriented abstractions, introducing a device driver framework with C++ driver support, and other changes...

http://www.phoronix.com/vr.php?view=MTgwMzQ

[Min1123]

Source?

A closer examination of the Google Cache on the site led me here:

http://dos.iitm.ac.in/projects/MOOL/

The Downloads section appears to require some sort of registration, but more telling is that the kernel version it appears to be based off of (for the 1.1 release) is still quite old (2.6.23). Additionally only the ne2k ethernet driver has been ported to their C++ driver layer with apparently a 2% overhead (Linux uses C with inline assembly for various architechtures for speed, so this doesn't seem to be a huge hit, I'd like to know the measurement technique used).

Seems like early days still, but a neat thing.

[uid313]

Linus is opposed to C++

Linus is opposed to C++ in the Linux kernel.

Mostly to filter out idiots so dumb people don't contribute to the kernel.
He wants a high barrier to entry to weed out crappy programmers.

Many programmers don't understand C++ and misuse it in various ways.

http://harmful.cat-v.org/software/c++/linus

[DataPath]

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

Meet BOSSMOOL, an effort to redesign the Linux kernel by adding object oriented abstractions, introducing a device driver framework with C++ driver support, and other changes...

http://www.phoronix.com/vr.php?view=MTgwMzQ

The kernel sources appear to be available here:

http://dos.iitm.ac.in/projects/MOOL/

The registration mostly serves as a click-wrap license presentation for the GPL (i.e. assurance that you've seen and accepted the license - lawyers are really big on that kind of thing).

Username: mool
Password: mool123

[stqn]

He wants a high barrier to entry to weed out crappy programmers.

That doesn?t make sense, as C is much easier to learn than C++.

But I agree that C++ is bad.

[souenzzo]

Nobody needs C++ for OOP.
You make make object orientation with C if you need.
Kernel should already use, GTK/GObjects use it.

[wagaf]

Nobody needs C++ for OOP.
You make make object orientation with C if you need.
Kernel should already use, GTK/GObjects use it.

What's wrong with C++ ?

OOP with C is indeed possible. It's just inconvenient & ugly.

GObjects may have awesome concepts, but C++ was made for OOP, code written in C++ is just so much easier to read, so much cleaner compared to "wanna be OO" C code. OOP is not just about the design pattern/programming paradigm, it's also about clean, readable, maintainable source code.

I understand kernel programming sometimes requires strict control over what's going on, but for the driver APIs and such, why being old-school for the sake of it ?

[bpetty]

Not bad

You could rewrite the Linux kernel in C++ without any of the C++ overhead typically associated with it.
It all depends on how it is written. For example, you could just use it for syntactic sugar (bool, class/namespaces, etc)... you don't need to create a bunch of v-table lookups.
I don't follow c11, but I assume it has "auto" like c++11. It would be interesting to take advantage of some of that too.

[Min1123]

Subject of post vs programming holy wars

The Linux kernel is C and assembly. All of the drivers are included within the source code, or as a portion of a shim module that is compiled against the source code.

No other major OS is based on something that does this. Windows has driver abstraction ABIs with their own APIs for things like NDIS and WDDM 1,0, 1.1, etc. Mac OS X has a binary ABI that can be targeted to make kernel modules that are compatible with numerous kernels with one binary package for drivers that are not packed in with the OS or a patch to it.

Linux meanwhile must be recompiled. This allows for constantly changing APIs, with no common or frozen ABI whatsoever. AMD tries to make their driver shims and closed-source stuff fit within this model, which is why it is always broken. NVidia doesn't bother, and essentially replaces most of what X is doing, with minimal involvement of kernel code or APIs, which is why their stuff almost always works.

So the conversation here, as I understand it, is that someone is making a fork of the Linux kernel that allows for device drivers to be separate from the kernel.

Abstraction helps markedly in this, but two specific features of C++ make this quite a bit easier, constructors and destructors. These allow the person making the driver to allocate all the resources they need to run properly, and then to specifically clean up after themselves when the driver is no longer needed and is unloaded.

This could be done by using a C API, but it is ingrained in C++ as a portion of the language. I don't see a need to bring Torvalds or his dislike of C++ into this, it is simply not the direction he chose to take, the same as with the drivers and embedding them.

[gamerk2]

The Linux kernel is C and assembly. All of the drivers are included within the source code, or as a portion of a shim module that is compiled against the source code.

No other major OS is based on something that does this. Windows has driver abstraction ABIs with their own APIs for things like NDIS and WDDM 1,0, 1.1, etc. Mac OS X has a binary ABI that can be targeted to make kernel modules that are compatible with numerous kernels with one binary package for drivers that are not packed in with the OS or a patch to it.

Linux meanwhile must be recompiled. This allows for constantly changing APIs, with no common or frozen ABI whatsoever. AMD tries to make their driver shims and closed-source stuff fit within this model, which is why it is always broken. NVidia doesn't bother, and essentially replaces most of what X is doing, with minimal involvement of kernel code or APIs, which is why their stuff almost always works.

So the conversation here, as I understand it, is that someone is making a fork of the Linux kernel that allows for device drivers to be separate from the kernel.

Abstraction helps markedly in this, but two specific features of C++ make this quite a bit easier, constructors and destructors. These allow the person making the driver to allocate all the resources they need to run properly, and then to specifically clean up after themselves when the driver is no longer needed and is unloaded.

This could be done by using a C API, but it is ingrained in C++ as a portion of the language. I don't see a need to bring Torvalds or his dislike of C++ into this, it is simply not the direction he chose to take, the same as with the drivers and embedding them.

Pretty much this times a million.