Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Nov 2007 13:38:03 -0700
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Bruce M Simpson <bms@incunabulum.net>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org
Subject:   Re: C++ in the kernel
Message-ID:  <20071102203803.GO77844@elvis.mu.org>
In-Reply-To: <472B52B2.9040901@incunabulum.net>
References:  <13151.1193483977@critter.freebsd.dk> <472B52B2.9040901@incunabulum.net>

next in thread | previous in thread | raw e-mail | index | archive | help
* Bruce M Simpson <bms@incunabulum.net> [071102 12:43] wrote:
> Poul-Henning Kamp wrote:
> >One major problem I see about a C++ runtime, is that it puts even
> >worse constraints on our compiler situation, raising the bar
> >significantly for any non GPLv3 compiler we might consider.
> >  
> 
> I agree with this point. I am certainly not suggesting that we become 
> more, not less, tightly coupled to a particular vendor's compiler.  I 
> believe Stroustrup would also agree on the first -- it must have occured 
> to him how to save people from reinventing the runtime support wheel 
> every time a new compiler comes out.
> 
> I agree with your other point regarding the isolation K seems to offer 
> in this respect. Re your last point, scanning the feeds it sounds like 
> Linux are having problems with GCC code generation too right now.
> 
> Anyway, I hope people do not form the opinion from this thread that 
> there is an Operation Impending C++ Doom up my sleeve -- there ain't -- 
> however I do feel the need to give people a whiff of the C++ coffee. It 
> is an advanced tool which has a high learning curve; it does have a 
> place in kernels and embedded systems; it's an industry fact of life; 
> like anything in life, it has its good and its bad.
> 
> Thanks for informed debate!
> BMS

A policy that might be interesting is to do something along
the lines of what we do with GPL, basically, core code in the
kernel can not be based on nor depend on it.  We could say the
same with any runtime/language added, at least for a time
period (probably a year or three) to make sure we don't grow
core dependancies on stuff we'll be sorry about later.

With such a policy in place, the "frightening" part about
supporting _any_ runtime really goes away and we can do whatever
we want.

Perlfs anyone?

-- 
- Alfred Perlstein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071102203803.GO77844>