Slashdot Mirror
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.
BeOS used C++. Microsoft Windows uses C++ -- albeit with the CRT (C Run Time) library separated.
Linus hates C++ for kernel development because C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling. The C++ committee would rather add a 2D graphics API that no one cares about to the language libs then focus on binary compatibility.
I'd argue, that the primary usefulness of C++ is for large developer-groups, where at least some programmers have vastly lower experience. It helps compartmentalize various things and hide internals. This is not all that useful, when the software project at hand is an operating system kernel — newbies should not be messing with that to begin with.
The other benefit of C++ — stricter compiler, which will flag various problems at compile time — is rather marginal, because commonly used C-compilers (clang, gcc) can be (and are) asked to do the same flagging as well. For example, here are the warning-flags used by my FreeBSD system to build its kernel: -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs...
In Soviet Washington the swamp drains you.
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.
Irony: Agile development has too much intertia to be abandoned now.
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated. In the presence of C++ inline functions, implicit type converters, copy constructors, and assignment operator overloads that ability goes right out the window. If you were managing a project that involved lots of small contributions from a large and widely distributed group of developers that inability to see what a small patch does would be fatal.
On a more subtle level, C++ rewards a well-thought out design that doesn't change very much, and mercilessly punishes a design that is produced incrementally in an evolutionary fashion. Given how Linux has developed over the years, C++ would have been a brutally punishing language for Linux.
I like C++, I've used C++ in quite a few projects. I will probably use C++ again. But I can easily see why the Linux kernel is not a great place to use C++.
I cannot see how introducing something like C++ will improve the situation. Changing the langauge doesn't get rid of evolutionary code, nor does it fix people's thinking. I can't fault the guys who evolved the musb driver into a working piece of code - the crux of the problems originate with the original Mentor documentation: Unavailable, poorly coverage of errata, poor detail on what the hardware block is doing.
What is required for good drivers are:
If hardware vendors wish to compete for embedded linux systems, then they should promote their performance on how well they do on the open test suite with their linux drivers - not just on their arm core's performance.
-bms
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.
Socialism: a lie told by totalitarians and believed by fools.
Every sufficiently large C project re-invents key portions of C++, poorly. I've been involved with a couple such efforts myself. There's just no excuse for the NIH-ism. The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Socialism: a lie told by totalitarians and believed by fools.
Like gcc, oh wait, not that is written in plain and simple c.
You misspelled "was". The compiler was switched over to C++ a few versions ago and they're now using C++ features.
SJW n. One who posts facts.
Because the compiler cannot guarantee correctness. That you think so is what make C++ and C++ developers so dangerous, especially in kernel space.
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Is C++ going to solve RCU and complex atomicity issues? Is C++ going to make run-time dynamic code generation easier? (That is, replacing NOP instructions at boot time for optimization and debugging.) No. In fact, C++ is worse for these things because C++ does too much implicitly, which makes it harder to reason about the code.
Before you opine on why C++ is better, why don't you download the C++11 and C11 specifications and read them thoroughly. Then contemplate how you'd write implementations for those. Then reassess how much, exactly, C++ simplifies anything.
Too many developers believe that as long as you _hide_ complexity, it has no cost. If it doesn't look complex on its face, how could it possibly hurt? Or by ignoring a feature you think it's magically disappeared. That's wrong on so many levels that it's difficult to even have a rational conversation with people who think that way.
Having been on the fence about this for a while, my experiences convinced me that C++ is wrong for the kernel.
The problem is not the extra features. The problem is that the programmer has little control over exactly how they are implemented: the compiler decides how to handle virtual method tables, destructors, multiple inheritence, etc. In the recent past, C compiler bugs have caused serious problems with Linux development. C++ compilation is an order of magnitude more complex, and you can bet it would be less reliable. This also means that C++ compiles much slower: doesn't sound like a big deal, but it is a cost to take into account.
The lack of a standard, clear ABI for C++ is also problematic. While it's true that Linux is monolithic, it still supports modules that interact with each other dynamically. Debugging C++ can be quite painful because of this. But it also means that it would be that much harder to contribute a module if it's not written exactly for the same compiler as the one used to build the kernel. Of course, it would have to be written in C++, too. This lack of flexibility can be quite painful in environments where you are limited to very specialized compilers (embedded). C has the most standard ABI of any language (well, C and Pascal). You can guarantee that *anything* would be able to interface with it.
So if you put the technical cons (losing control, flexibility and debugabbility) vs. the pros (cleaner syntax) then it's right to pick C, on technical grounds. As others have stated here, anything you can do in C++ you can do in plain C. It's a bit clumsier, but then you have complete control over the implementation. I do OOP in C all the time, it's perfectly OK. If anything, a bit more powerful than C++, because I tailor the OOP features to exactly my needs and tastes.
Beyond that, there is the more controversial issue of programmer culture. C++ hides away implementation details, but for kernel development you want programmers who think about every tiny issue of implementation: exactly what is going on with the call stack, what is a pointer and what isn't? The more explicit nature of C encourages a more hard-nosed stickler for technical correctness, which is more important than pretty code for kernel work.
By the way, I'm writing this as a former C++ zealot. I even created something like this in the past, a C++ wrapper for Windows NT networking services. I found out the hard way that C++ takes more than it gives. I write all my code in C these days, and don't feel like I'm missing anything.
If you don't think Linus has enough C++ experience, how about the man who created of C++ as a hoax, Bjarne Stroustrup:
Interviewer: If we publish this, you’ll probably get lynched, you do realise that?
Stroustrup: I doubt it. As I said, C++ is way past its peak now, and no company in its right mind would start a C++ project without a pilot trial. That should convince them that it’s the road to disaster. If not, they deserve all they get.. You know, I tried to convince Dennis Ritchie to rewrite Unix in C++..
Interviewer: Oh my God. What did he say?
Stroustrup: Well, luckily, he has a good sense of humor. I think both he and Brian figured out what I was doing, in the early days, but never let on. He said he’d help me write a C++ version of DOS, if I was interested..
Interviewer: Were you?
Stroustrup: Actually, I did write DOS in C++, I’ll give you a demo when we’re through. I have it running on a Sparc 20 in the computer room. Goes like a rocket on 4 CPU’s, and only takes up 70 megs of disk..
Interviewer: What’s it like on a PC?
Stroustrup: Now you’re kidding. Haven’t you ever seen Windows ‘95? I think of that as my biggest success. Nearly blew the game before I was ready, though..
Interviewer: You know, that idea of a Unix++ has really got me thinking. Somewhere out there, there’s a guy going to try it..
Stroustrup: Not after they read this interview..
Obviously the BOSS-MULL developers never did read it. You can here.