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.
You're making that up. Linus's actual arguments against C++ for kernel is mainy rhetoric about "substandard programmers". The real issue is that Linus has no real experience with C++, therefore does not deeply understand its organizational advantages. Speaking as a longtime C hacker who did make the effort to figure out what C++ is all about. It's true, C++ is far from perfect, but on the whole it beats the crap out of good ole C along multiple dimensions.
When all you have is a hammer, every problem starts to look like a thumb.
well, that's pretty a rather sweeping statement which would incur a lot of context switching just to make you happier.
The Windows kernel APIs are all C, there is no C++ in it. You can use a subset of C++ that doesn't require runtime support, but it is unsupported.
Linus hates C++ for a lot more reasons than ABI, and the majority of them are completely uninformed and show a lack of C++ experience.
All the understandability and maintainability worries people have about C++ in the kernel would be easily controlled by standard patch review. Don't like giant template metaprograms? Don't accept the pull request. That easy. Perhaps one of the valid reasons to keep C++ out of the kernel right now is purely that Linus would be unable to review such patches with authority.
Even simple things like classes, RAII, basic templates, and exceptions would do wonders for development.
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++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling
IIRC from Stroustrup, non-standardized name mangling is considered a feature because it acts as a public interface for many other non-standardized incompatibilities under the hood. Without it, it would be possible to link code emitted from different C++ compilers that would fail to interoperate properly in subtle and difficult-to-debug ways.
So it isn't quite fair to imply that if only name mangling were standardized the problem would go away: it would really require a very large enhancement to the standard that would deal with all the different ways that compilers do things now. That potentially involves a vast amount of work on understanding current compiler technology, much of which would likely be obsolete by the time the standard shipped. Ergo: compiler compatibility is unlikely to ever happen.
I'm not saying this is a good thing, just that it's a thing. I currently code in C, C++ and Python, and C++ is by far the most difficult, dangerous and awkward of the three (or of any language I've ever coded in, really) but the additional power does make it worthwhile in certain circumstances.
Blasphemy is a human right. Blasphemophobia kills.
Can anyone really argue with this:
Yes, mostly because it's crap filled with logical fallacies and a staggering ignorance of C++. I would respond, but someone already did it better:
http://ridosandiatmanto.wordpr...
I *do* like the ability to free up resources in a c++ destructor, but as he points out, that's not something you want to rely on in system software.
Don't see why not. Would you ever want to forget to unlock a mutex? Why not let the compiler guarantee correctness rather than have to do it by hand every time.
SJW n. One who posts facts.
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++.
The Linux kernel makes heavy use of big ugly, hard to maintain or read macros that generate arbitrary machine code. No matter how good you are, you won't know what code is being generated without extensive analysis. In any case, the exact same ugly macros can be used by C++, if you are really wedded to that kind of bad taste. C in fact has no addtional features in this area, it only lacks features that C++ has.
If you want to point at features that C has which C++ does not then you get a very small set, which in the case of the kernel consists mostly of designated initializers.
When all you have is a hammer, every problem starts to look like a thumb.
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.
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.
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.
Replacing macros with templates and long functions names aren't exactly the killer benefits most people think about for C++. It's typically things like avoiding memory corruption and resource leaks, which can both be really bad in an OS kernel. Even so, I'd argue that they DO buy kernel developers something. Macros are completely type unsafe, and can silently generate bugs. More sanely named overloaded functions and namespaces help to make code more readable. Are kernel developers somehow magically exempt from features the rest of the world finds useful?
Still, even as a C++ advocate, I would never really argue that C++ solves all problems, is easier to use, has no hidden costs, or even is the correct language to use in all situations. Good C++ programmers understand the costs of features they are using and the tradeoffs they're making. There are bad programmers in every language, including C++. Personally, I'll probably always choose C++ for my own projects that require high-performance native code because it provides some very significant benefits:
1) Using class based abstractions can virtually eliminate some really dangerous categories of bugs like buffer overruns.
2) It's almost impossible to leak memory or resources with properly designed wrapper/interface classes.
3) Well written C++ interfaces can make it harder to misuse APIs in general
4) These benefits are typically provided at either zero or with minimal overhead. There is no "hidden" overhead if you understand how the language feature or library works.
5) For times that this overhead is critical, you can revert back to C. For all other cases, you can prefer the higher-level abstractions and the safety and convenience they provide.
Generally speaking, I'd say it's harder to write good C++ code and design great C++ interfaces. However, once those interfaces are created, they tend to be far easier and safer to use - even for the person who originally wrote them. Most of my own library classes are designed in such a way that I couldn't cause crashes, leaks, or memory corruptions with them unless I tried really hard to do so using blatantly unsafe techniques (which C++ lets you do, of course, just like with C).
If I had to sum up, the significant benefit of C++ is that it makes it possible to protect the programmer from making mistakes to a much greater degree than in C while retaining most of the performance benefits of C. We've seen it demonstrated quite clearly, time after time after time... programmers are only human, and will always make silly mistakes. Why not take advantage of the language and compiler to help minimize the chances of making those mistakes in the first place? To me, that's the essence of C++.
Irony: Agile development has too much intertia to be abandoned now.
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.
The fact that *EVERY* line of kernel code has to deal with those kind of issues is a byproduct of the monolithic kernel design, not what the code itself is doing.
I started off as a Unix kernel programmer in the late-80's, did a lot of stuff on supercomputers and went to Apple to work on Copland (micro-kernel). I/O subsystems can make good use of OO abstractions. OS X's IO subsystem is written in C++.
It's really time to look at microkernels again. There are some performance issues, but many of those will get smoothed out as they're hit and engineered around.