C++ in the kernel

Alfred Perlstein alfred at freebsd.org
Mon Oct 29 22:58:54 PDT 2007


* Garance A Drosehn <gad at FreeBSD.org> [071029 22:50] wrote:
> At 7:46 AM +0000 10/28/07, Poul-Henning Kamp wrote:
> >In message <20071028074310.233895B3E at 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.
> >
> >The other main argument is that we can then teach the language to
> >do the things we need it to do.
> 
> This seems like a good idea to me, as long as the language we come
> up with is just some easy-to-follow additions to the C language.  (I
> believe that has always been your intention, but I just thought it
> would be good to say it again).  That way we don't get caught up in
> problems when, say, the ABI's for the official C++ language are
> changed, and we don't want to make major ABI changes in the middle
> of a STABLE branch.
> 
> It might be prudent to say we're building a new language patterned
> on something *other* than C++, just to make it clear that we won't
> be tied to whatever developments coem up in the world of C++.
> 
> I've been meaning to look into D, but I don't have any experience
> with programming in D, so I don't know if that would work as a
> basis of a kernel-programming language.  (Not that we'd use the
> official D language, either.  Just that it might be a source for
> ideas of whatever we want to do)

I think the right thing to do here is to identify the things we
need added to C++ and propose those to the standards.  If they
are reasonable and useful then it should be something that
passes and we will wind up with something the industry uses
rather than some graduate project while Linux eclipses us
even further because they took something that worked.

-- 
- Alfred Perlstein


More information about the freebsd-arch mailing list