C++ in the kernel

[Peter Jeremy]

On Mon, Oct 29, 2007 at 08:22:22PM +0000, Poul-Henning Kamp wrote:
>Not really.  I've personally bugged Bjarne about making C++ usable
>for systems programming ever since 1987 or so, but to no avail.

I can also see some benefits in parts of C++ - we already simulate
bits of classes, inheritance and templates in the kernel and having a
language where this was an integral part of the language should
improve code readibility and reduce scope for errors.  I also agree
that C++ brings with it far too much baggage and allowing a useful
subset into the kernel would lead to the rest of the camel following
over time.

>One thing that particularly bothers me, is that compilers offer
>no assistance in debugging, because normal programming runs in the
>UNIX virtual machine, attaching a debugger is the preferred way.

Virtualisation offers one way of making kernel debugging less painful
but I agree that debugging a mis-behaving kernel is much harder than
debugging a userland application.

>Imagine for instance an option to zap the heap with 0xdeadcode on
>function return or an option to check all function pointers for
>non-null-ness before jumping through them.

Both these should be fairly simple patches to gcc.  The former would
be useful in application programming as well as kernel programming and
could therefore make it back into the vendor gcc.

I don't really see the benefit of the latter - calling a NULL function
pointer will immediately trap and trigger a panic.  For much of the
kernel, it's not clear what else to do.  Possibly there are some cases
where the kernel could take recovery action and continue but that
requires much finer control than a compiler switch - it would seem
easier (and more efficient) to add code into the trap handler to
recover from expected traps (much as copyin() and copyout() do now)
than add a conditional test to every call instruction.

Note that neither of these imply a change to the language.

Maybe, in another thread, you might like to discuss your ideas for what
additional features our development toolkit should have to assist with
kernel development.

-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20071030/92def06b/attachment.pgp