Why don't we rewrite the Linux kernel in
* (ADB) Again, this has to do with practical and theoretical
reasons. On the practical side, when Linux got started gcc
didn't have an efficient C++ implementation, and some people
would argue that even today it doesn't. Also there are many more
C programmers than C++ programmers around. On theoretical
grounds, examples of OS's implemented in Object Oriented
languages are rare (Java-OS and Oberon System 3 come to mind),
and the advantages of this approach are not quite clear cut (for
OS design, that is; for GUI implementation KDE is a good example
that C++ beats plain C any day).
* (REW) In the dark old days, in the time that most of you
hadn't even heard of the word "Linux", the kernel was once
modified to be compiled under g++. That lasted for a few
revisions. People complained about the performance drop. It
turned out that compiling a piece of C code with g++ would give
you worse code. It shouldn't have made a difference, but it did.
Been there, done that.
* (REG) Today (Nov-2000), people claim that compiler
technology has improved so that g++ is not longer a worse
compiler than gcc, and so feel this issue should be revisited.
In fact, there are five issues. These are:
o Should the kernel use object-oriented programming
techniques? Actually, it already does. The VFS (Virtual
Filesystem Switch) is a prime example of object-oriented
programming techniques. There are objects with public and
private data, methods and inheritance. This just happens to be
written in C. Another example of object-oriented
programming is Xt (the X Intrinsics Toolkit), also written in C.
What's important about object-oriented programming is the
techniques, not the languages used.
o Should the kernel be rewritten in C++? This is
likely to be a very bad idea. It would require a very large
amount of work to rewrite the kernel (it's a large piece of
code). There is no point in just compiling the kernel with g++
and writing the odd function in C++, this would just result in a
confusing mix of C and C++ code. Either the kernel is left in C,
or it's all moved to C++.
To justify the enormous effort in rewriting the
kernel in C++, significant gains would need to be demonstrated.
The onus is clearly on whoever wants to push the rewrite to C++
to show such gains.
o Is it a good idea to write a new driver in C++? The
short answer is no, because there isn't any support for C++
drivers in the kernel.
o Why not add a C++ interface layer to the kernel to
support C++ drivers? The short answer is why bother, since there
aren't any C++ drivers for Linux. However, if you are bold
enough to consider writing a driver in C++ and a support layer,
be aware that this is unlikely to be well received in the
community. Most of the kernel developers
are unconvinced of the merits of C++ in general, and consider
C++ to generate bloated code. Also, it would result in a
confusing mix of C and C++ code in the kernel. Any C++ code in
the kernel would be a second-class citizen, as it would be
ignored by most kernel developers when changes to internal
interfaces are made. A C++ support layer would be frequently be
broken by such changes (as whoever is making the changes would
probably not bother fixing the C++ code to match), and thus
would require a strong commitment from someone to regularly
o Can we make the kernel headers C++-friendly? This is
the first step required for supporting C++ drivers, and on the
face seems quite reasonable (it is not a C++ support layer).
This has the problem that C++ reserves keywords which are valid
variable or field names in C (such as private and new). Thus,
C++ is not 100% backwards compatible with C. In effect, the C++
standards bodies would be dictating what variable names we're
allowed to have. From past behaviour, the C++ standards people
have not shown a commitment to 100% backwards compatibility. The
fear is that C++ will continue to expand its claim on the
namespace. This would generate an ongoing maintenance burden on
the kernel developers.
Note that someone once submitted a patch which
performed this "cleaning up". It was ~250 kB in size, and was
quite invasive. The patch did not generate much enthusiasm.
Apparently, someone has had the temerity to label
the above paragraph as "a bit fuddy". So Erik Mouw did a short
back-of-the-envelope calculation to show that searching the
kernel sources for possible C++ keywords is a nightmare. Here is
his calculation and comments (dates April, 2002):
% find /usr/src/linux-2.4.19-pre3-rmap12h -name "*.[chS]"
xargs cat | wc -l
So there's over 4 million lines of kernel source.
Let's assume 10% is
comments, so there's about 3.6 million lines left.
Each of those lines
has to be checked for C++ keywords. Assume that you
can do about 5
seconds per line (very optimistic), work 24 hours
per day, and 7 days
5 s 1 hour 1
day 1 week
3600000 lines * ------ * -------- * ---------- *
-------- = 29.8 weeks
line 3600 s 24 hours 7
Sounds like a nightmare to me. You can automate
large parts of this,
but you'll need to write a *very* intelligent
for that. Better use that time in a more efficient
way by learning C.
Note that this is the time required to do a proper
manual audit of the code. You could cheat and forgo the auditing
process, and instead just compile with C++ and fix all compiler
errors, figuring that the compiler can do most of the work. This
would still be a major effort, and has the problem that there
may be uses of some C++ keywords which don't generate a compiler
error, but do generate unintended code. In other words,
introduced bugs. That is not a risk the kernel development
community is prepared to take.
My personal view is that C++ has its merits, and makes
object-oriented programming easier. However, it is a more
complex language and is less mature than C. The greatest danger
with C++ is in fact its power. It seduces the programmer, making
it much easier to write bloatware. The kernel is a critical
piece of code, and must be lean and fast. We cannot afford
bloat. I think it is fair to say that it takes more skill to
write efficient C++ code than C code. Not every contributer to
the linux kernel is an uber-guru, and thus will not know the
various tricks and traps for producing efficient C++ code.
* (REG) Finally, while Linus maintains the development
kernel, he is the one who makes the final call. In case there
are any doubts on what his opinion is, here is what he said in
In fact, in Linux we did try C++ once already, back in
It sucks. Trust me - writing kernel code in C++ is a
BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were
even worse in 1992, but some fundamental facts haven't changed:
o the whole C++ exception handling thing is
fundamentally broken. It's _especially_ broken for kernels.
o any compiler or language that likes to hide things
like memory allocations behind your back just isn't a good
choice for a kernel.
o you can write object-oriented code (useful for
filesystems etc) in C, _without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel
modules for C++ is either
o (a) looking for problems
o (b) a C++ bigot that can't see what he is writing is
really just C anyway
o (c) was given an assignment in CS class to do so.
Feel free to make up (d).