Why wasn't the Linux kernel written in C++?
kerneltrap.org
kerneltrap.org
The OP is roundly criticized for even considering writing a kernel module in C++. The authors of the module had to patch the Linux kernel heavily to make the headers compile as C++, and of course the patches for 2.4 don't all work for 2.6.
I can agree that if you patch the crap out of an open source project, be it the kernel or just a library, to make it work with your own code, then you get what you deserve when it gets out of sync with the upstream version and no longer is compatible. How could it be otherwise?
But as an experienced C++ hacker I disagree with the argument the C hackers made in the discussion that "you just can't use C++ there, you must use C" (to paraphrase).
The problem isn't that they chose the "wrong" language, it's just that they interfaced the C++ code with the C (kernel) code incorrectly. The Right Way would be to simply write a compatibility layer in C that calls functions in the C++ code. And the C++ code could in turn call back to C functions in the compatibility layer when they need to interface with some kernel data structure. Although performance is listed as an issue, they specifically say that their module gets its performance benefit by not having to copy packet data to user space. They would still get this benefit, even if they had the minuscule extra time it takes to make a call through a C/C++ compatibility layer.
The Linux people will look at you funny for doing it, but you can in fact write a kernel in C++.
I think this back and forth sort of breaks down because people say things like C and C++ and it's not clear if they're talking about
1) The languages themselves. 2) The compilers 3) Possible runtimes and other overhead that need to be considered in a stereotypical environment (that is, probably not kernel coding). It tweeks me every time we get into a language war, because a lot of the time the language itself isn't the real point of discussion, but rather it's some sideways way of referring to the toolchain that's popular at the given moment. C++ as a language could very well be tooled to write a kernel, given a good compiler and a semantics that coders stick to (just like C). I feel like the C++/HLL camps are crying for something other than C because they're not interested in the super low level details, but still would like to eek some functionality out of the kernel. They're basically saying, "we would prefer tools other than C" (regardless of whether C++ is a worthwhile and better option, I am unconvinced).
I think an even more interesting conversation to have would be: have operating systems kernels become TOO COMPLEX to code in (just) C/ASM? Are we in over our heads? Should we invest in the creation of better tools to handle such large, complex systems or is everything just fine?
DISCLAIMER: I actually don't like programming in C++. I will put up with C, but I usually find myself writing in Ruby or Haskell.
I fundamentally disagree with the notion that you can write /good/ kernel code in a HLL. A kernel is ALL ABOUT interacting with the hardware and performing low level system management. Sure, you could write kernel code in a HLL, but it is just not going to be as performant as if you wrote the code with "the super low level details" in mind. These are important considerations that compilers do not have insight into. I would go on to argue that to anyone who understood the low level details required to write quality kernel code, those details are not something they wish to overlook. Anyone who doesn't understand those details shouldn't be writing kernel code.
There is a limit to what a hacker can keep in his head at once. You may believe your limit is high, but it does exist. If you eschew abstraction, there is a class of programs you cannot write because you can't keep the complexity managed. This is why it irks me when I see arguments against abstraction - they are short sighted.
Now, there are some perfectly good concrete examples of things C++ compilers do which may not be a good idea in kernel code. For instance, C++ exceptions can cause trouble when the stack alternates between C++ and C frames.
C is all about subroutines (functions), jumps (function calls), pointers and quantities that map directly to registers (int, long) — for the most part a fairly thin veneer on top of modern CISC/RISC machine code.
For those abstractions (such as the call stack) that are essentially black boxes, there is the C ABI, which explicitly defines much of the underlying structure.
Exactly. A million times, exactly.
There's a link in here to a book PDF that attempts to teach OO techniques in C. http://www.cs.rit.edu/~ats/books/ooc.pdf
Personally I think it doesn't even matter. The kernel is stuck with C, they couldn't port it even if they wanted to.
This is a lie.
Because C++ is such a poorly designed language, it is extraordinarily hard to make a (relatively) correct, let alone high performance compiler. Language complexity matters when you're writing a compiler, and C++ is every compiler writer's worst nightmare.
For example, I see no discernible overhead at all in iterating through an std::vector vs a bare C array.
The STL code is highly optimized and there should be no technical reason why it would consume more memory or lead to code bloat.
The upcoming Ada 2012 standard even includes versions of Ada 2005's collection classes which are allocation-free (read: pre-allocated to a size specified at creation time, and guaranteed not to perform allocation after that point).
Ada's generic programming was a big influence on Stepanov's design of what became the STL (the first versions were a port of work he had done under Ada). Ironically, the Ada standards process moved so slowly that by the time Ada grew standards-mandated generic collection classes (previously this was something all vendors provided as an extension), it had time to learn the lessons of STL.
(Not a knock on STL, by the way -- STL's implementors have learned a lot over the life of the standard as well.)