C++ in the kernel

George V. Neville-Neil gnn at neville-neil.com
Wed Oct 31 04:07:41 PDT 2007

Not to jump in here and ruin the thread, but unless I missed
something, the thing that's missing here is the grounding, that is,
"What do we need C++, or for that matter, a kernel language for?"

When Poul-Henning and I talked about K, and when I saw what a hash has
often been made of kernel like systems (RTOSs as well as bigger OS
Kernels) the list that popped into my mind had bits of this

1) Better support for locking primitives

That is, locking primitives that can be better instrumented etc.

2) Support for components.

Right now this can be done with klds but something like them as a
first class feature of a language would be useful to us.

3) Something like the STL.  It would be nice if we didn't re-invent
the (as Kip put it) CS101 primitives.

The problems with C++ are both political and technical.  The political
are likely the more formidable ones, but let's face it we're doing C++
like things in the kernel now (structures of pointers ARE vtables, and
vice versa).  It might be that a small extension to C is the right way
to move towards a more powerful set of tools for kernel developement
without scaring people with the C++ bogeyman (bogeyperson? ;-)

What is needed to move all this forwards is either one of the

1) A serious proposal on C++ in the kernel that includes:

  a) The restricted subset of C++ we would be willing to entertain.

  b) A demonstration of the kernel built and running from a C++

2) A serious proposal on a C extension language that includes:

  a) The list of primitives that are being added, their purposes, and
  how they are better than what we have now.

  b) A demonstration of the kernel built and running from such a set
  of extensions.

The biggest problem here is that we'd need people committed to doing
this who can work with the community.  I believe this is why the K
efforts, which I have been a part of and take some responsibility for,
have failed.  You need a group of people with experience and drive to
make this work, not a bunch of us hand waving in email.


More information about the freebsd-arch mailing list