
Why don't we rewrite the Linux kernel in C++? - vinutheraj
http://www.tux.org/lkml/#s15-3
======
bobbyi
Linus on C++: [http://article.gmane.org/gmane.comp.version-
control.git/5791...](http://article.gmane.org/gmane.comp.version-
control.git/57918)

~~~
chanux
That concludes the talk.

------
vinutheraj
Actually I suggest the whole Linux FAQ because of many good explanations to
questions like why isn't the linux kernel a microkernel and why aren't the
gotos replaced with C style exceptions.

They give a pretty good answer to latter question - _Admittedly, all those
goto's do look a bit ugly. However, they are usually limited to error paths,
and are used to reduce the amount of code required to perform cleanup
operations. Replacing these with Politically Correct if-then-else blocks would
require duplication of cleanup code. So switching to if-then-else blocks might
be good Computer Science theory, but using goto's is good Engineering. Since
the Linux kernel is one designed to be used, rather than to demonstrate
theory, sound engineering principles take priority._

It is definitely a _nice reading on a rainy afternoon_

~~~
duskwuff
Sadly, I get the feeling that the FAQ - or, at least, this version of it - has
been badly neglected. Many of the answers were written quite a while ago,
rendering the answers misleading or just plain wrong. Many of the answers
refer to 2.4 as the current "stable" kernel, dating them to 2004 or earlier.

------
jongraehl
It sounds like they took someone's patch, which renamed some identifiers to
not conflict with the handful of new keywords added in C++, and ignored it.

Then they bragged about it.

That seems to be more political than technical.

~~~
Locke1689
I'd say the exact opposite. What is the point of replacing the conflicts with
C++? Torvalds makes a very good case for not using C++ in the Linux kernel. At
the very least, it seems like hiding memory allocation in kernel level code is
a recipe for disaster. Of course, one could argue that you can use malloc in
C++ just as well as in C, but then are you really writing C++? It seems as
though you're writing C code in C++. In fact, many of the language "features"
that C++ offers seem to be Very Bad Ideas(TM) in the kernel.

In addition, as Linus responded earlier, anyone who has written a modicum of C
code knows that you don't need the complex language features of C++ to write
modular, object oriented code (in fact, I'd argue that C++ is a blight upon OO
and should probably die a horrible death, but that's neither here nor there).

Most notably, however, is simply that it is not the Linux team's
responsibility to defend their use of C over C++ -- given the amount of code
that must be adapted, it is more appropriate for the C++ devs to argue what
heavy benefits _C++_ has in its favor (such that they merit the transformation
of a complex and significantly large body of code).

I would actually say the C++ dev's view is more political than technical:
advocating the switch to C++ "just because," implies a political (or
religious) reasoning, while the Linux team's view seems much more technical.

~~~
wglb
As someone who has done some seriously low-latency projects on C++, there are
really many levels that you can do this at. You can turn off exceptions, do
constructors very sparingly, handle your own memory management and so on. As
was said by its creator, C++ is a multi-paradigm programming language.

There is something to be said for doing a lot of kernel stuff in template
metaprogramming.

~~~
swolchok
(Could've sworn this was in C++ FAQ Lite, but I can't find it) The language
specifies exceptions as a feature, not an option. Turning off a language
feature and how that works with other features that may reference it is a
heavily compiler-specific endeavor, and isn't C++.

~~~
wglb
Yes, you are correct. In my high-performance version, I used an extension of
the language provided by g++ which allowed turning off of exceptions, which
sadly cost time even if you don't use them.

------
tptacek
There already are projects that run C++ code in the Linux kernel; the Click
Modular Router from MIT PDOS is C++, for instance. It's probably prohibitively
annoying to write mainline kernel code, like a device driver, in C++. There
might not be anything to prevent you from loading a whole C++ subsystem,
though.

I'll head some other commenters off at the past and note that MacOS X xnu has
a C++ device driver interface, but is still a C-code kernel.

Linus is right about the exception handling and allocator issues. C++
exceptions are a misfeature in userland code; it's even more important for
kernel code to be able to handle problems gracefully and explicitly, and
unwinding stacks through functions running at different interrupt
sensitivities and holding different locks seems like an disaster waiting to
happen. And, unless my C++ has gotten rusty since Alexandrescu's book came
out, nobody likes the C++ allocator interfaces --- which you'd certainly have
to dive into to handle the kernel's various different allocation strategies.

------
wglb
I think it would be more interesting to do it in D.

~~~
Locke1689
With... automatic memory management? What? That's the last thing that I think
would help.

~~~
w1ntermute
Manual memory management is also possible in D
(<http://www.digitalmars.com/d/2.0/memory.html>).

~~~
Locke1689
Didn't know that, thank you. Learn something new every day.

------
Bjoern
For polyglots it is interesting also to know why C/C++ got so popular in the
first place.

JWZ - The worse is better.

<http://www.jwz.org/doc/worse-is-better.html>

~~~
Locke1689
Why was this downvoted? He has a differing viewpoint, but I think its a
compelling argument. Not altogether off-topic either (especially when you
consider people talking about implementing OS kernels in things like Java or
D).

------
rbanffy
I learned OOP in Smalltalk. Then I decided to learn C++. The first code
snippet I saw used the overloaded shift operator to push strings to stdout. I
closed the book.

It took me 8 years to try to learn C++ for a second time. This time I insisted
and more or less got through.

C++ is not as bad as my first impression led me to believe, but it's not as
good as its enthusiasts insist it is. For instance, and quite predictably for
a Smalltalker, I find Objective-C much more elegant.

It seems foolish to implement something like this in C++

------
chanux
Why I see people talking about OSes a written in high level languages a lot
lately?

Remember the C# one came on HN? <http://daeken.com/renraku-future-os>

I think an OS written in an OO language will demonstrate why some people were
actually worried about OOP. <http://www.geocities.com/tablizer/oopbad.htm>

------
tybris
Weird question, what's wrong with C? A simple, elegant, efficient language
that is close to the metal.

~~~
wglb
Ah, but why does it have to be close to the metal?

~~~
wglb
Keeping in mind that <http://en.wikipedia.org/wiki/Multics> was programmed in
PL/1 and assembler, and may have generated more ideas than Linux or Unix.

------
known
Why don't we rewrite JVM in Java?

------
Zarathu
"...and furthermore, C++ is slow as piss."

~~~
lallysingh
Ugh, old, old FUD from years back (not you, the article). g++ (the only C++
compiler that's relevant) has been as fast as gcc for years (they use the same
back-end).

After this was released:
[http://developers.slashdot.org/article.pl?sid=04/10/27/21102...](http://developers.slashdot.org/article.pl?sid=04/10/27/2110228)
(the original link is lost, but I'll summarize below), and the community
ignored it, I stopped really respecting the technical merits of the Linux
community. It's a hacker's hobby that became good enough in a group of systems
that stagnated (see <http://doc.cat-v.org/bell_labs/utah2000/> ).

<rant ignore="recommended"> Frankly the quick reason is that the kernel is a
hobby for many, and a fetish for some. Engineering decisions are made at the
geek level, not a management level, e.g., "This cool hack will make it faster
for the $250k big-iron box I got on eBay" vs "We should put together a unified
infrastructure for making 802.11 easy to use." </rant>

<sidebar title="Linux on C++ Patch"> The work I mentioned above (to the side?)
was an effort to make the kernel compile on g++. They also made exception
handling faster than printk(). Like it or not, a lot of techniques used in a
"modern" unix kernel are language features in C++, e.g., vnodes/vtables. On
top of that, exceptions provide a much more structured way to describe (via an
entire type system, not just error codes!) and handle (catch what's relevant
to you, pass on what's not) errors, with the ability to automatically clean up
resources and state along the way (local variable destructors, the 'operate-
and-swap' idiom for stl containers).

But no, all we have is ~15 yr old FUD quoted over and over, ironically similar
to the windows users they love to complain about. </sidebar>

~~~
pbiggar
> Ugh, old, old FUD from years back (not you, the article). g++ (the only C++
> compiler that's relevant) has been as fast as gcc for years (they use the
> same back-end).

g++'s generated code is not as fast as gcc's, despite their common
infrastructure. For the last month or two, gcc has been compilable with g++ as
well (it has been rewritten in the common C/C++ subset), and the reports are
of about a 10% decrease in speed when compiling with g++.

~~~
lallysingh
Odd, CPU-wise it does pretty well here:
[http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=gpp&lang2=gcc&box=1)

(g++ vs gcc in the language shootout).

I'm gonna guess gcc's been optimized for compilation by gcc (or at least the
bootstrap version), and that no such optimization's been done for g++.

~~~
malkia
Don't believe one benchmark.

In reality any C++ code can (and it's internally) translated to C one (that's
called the front-end compiler). The back-end is the same.

The only difference is when there are things required by the C++ runtime
(mainly exceptions and RTTI, and in some sense virtual functions).

I'm sure that if you take a "C" code, and compile it under "C++" compiler
(given that it can compile) - you won't see difference.

Please disassemble it, and see for yourself.

That's the other problem with C++ - no one actually for real writes in full
C++ - you always end up sacrificing features (exceptions most notably) to have
running on embedded systems, or game consoles. And no RTTI there too.

