Object Oriented Linux Kernel With C++ Driver Support

An anonymous reader writes: An effort underway called BOSS-MOOL, the Minimalistic Object Oriented Linux, is designing the Linux kernel with OOP and C++ driver support. Linus Torvalds' opinions on C++ have long been known while developers at the DOS Lab IIT Madras and CDAC Chennai feel redesigning the kernel with object oriented abstractions and C++ driver support will increase maintainability while reducing complexity of the kernel. It doesn't appear though the group will try to mainline these changes.

Comments

Re:Why do people still care about C++ for kernel d

[Dutch Gun]

C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it and use good judgement in applying any given feature. I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C. More critically, C++ interfaces and methods can be written in such a manner as to provide much better protection to the programmer from his own mistakes. It's much harder to do that in C. In today's security-conscious world, where a single mistake can mean a critical OS vunerability, that's a real issue.

Essentially, C++ is C plus the ability to create powerful abstractions, typically expressed in objects/classes and templates, but not necessarily limited to those. Those abstractions put more of a burden on the compiler rather than the programmer, and as a result, is much safer than anything one could write by hand. All raw memory buffer manipulation, for instance, can be done through carefully protected wrapper objects or other user-defined primitives, and there's no reason in modern C++ to manipulate object lifetime through raw pointers, as it now has standardized smart pointers. Any resource - memory, file, locks, handle, etc, should be lifetime managed by objects - and so modern C++ should feel a lot like a garbage-collected language. In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management (e.g. IDisposable in C#).

It's certainly not a language suitable for all tasks, and it arguably requires more expertise than C to use it well. However, systems programming is absolutely one of those things it's well suited for. Binary compatibility would be great to have, but is not a real hurdle. To work around it, you can simply fall back to a C-like API at module boundaries, and avoid passing any objects across. That's what I typically do when I have to write C# C++ interop layers, and it's worked pretty well for me. While it brings along a lot of cruft, C compatibility, including it's binary compatibility, is one of C++'s great strengths as a language.

Re:Why do people still care about C++ for kernel d

[lgw]

In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management

The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.

I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion. In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz. In Java, even with the better garbage collector designed for servers, "bouncing off the roof" is the norm, and it's quite hard to tell when danger is approaching.

I'd be interested in any /.er advice here - is there some dependable way with Oracle Java to measure "real heap size" - the total size of objects actually in use? The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.