Date: Mon, 29 Oct 2007 20:22:22 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel Message-ID: <33676.1193689342@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 29 Oct 2007 11:12:36 %2B0100." <fg4bij$m42$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <fg4bij$m42$1@ger.gmane.org>, Ivan Voras writes:
>Poul-Henning Kamp wrote:
>> In message <20071028074310.233895B3E@mail.bitblocks.com>, Bakul Shah writes:
>>
>>> It will be the proverbial camel's nose in the tent. A subset
>>> of C++ is attractive for kernel work but it will be hard to
>>> hold the line at that.
>>
>> That's one of my main arguments why we should "own the language" we
>> use.
>
>A bit of the "NIH syndrome" here? :)
Not really. I've personally bugged Bjarne about making C++ usable
for systems programming ever since 1987 or so, but to no avail.
If you look at kernel code, you will find that the kind of things
we do there, are slightly but importantly different from what C++
and other more modern languages are built to handle.
For instance, the entire "dual-address space" dictomy og system
calls/copy{in,out} and the very concept of interrupts are very
tricky to sensibly express in anything but C.
So what I've been tinkering with, is not a new language, but a
C dialect enhanced to make kernel programming simpler.
>> The other main argument is that we can then teach the language to
>> do the things we need it to do.
>
>The less people know the language, the less it will be used. A "one-off"
>language (like "K") applicable only for FreeBSD is not exactly doomed to
>popularity.
I'm not trying to come up with a language to end all languages, I
leave that for greater minds than mine. All I want is a compiler
and a language that makes it easy for me to write bugfree, efficient
and readable kernel code.
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.
In the kernel we don't have that luxury, and there are a number
of ways the compiler could help us.
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.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33676.1193689342>