From owner-freebsd-arch@FreeBSD.ORG Fri Nov 2 21:56:30 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFDD216A473 for ; Fri, 2 Nov 2007 21:56:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C1F5D13C4BB for ; Fri, 2 Nov 2007 21:56:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 344651A4D82; Fri, 2 Nov 2007 14:31:55 -0700 (PDT) Date: Fri, 2 Nov 2007 14:31:55 -0700 From: Alfred Perlstein To: Poul-Henning Kamp Message-ID: <20071102213155.GS77844@elvis.mu.org> References: <20071102203803.GO77844@elvis.mu.org> <4755.1194036771@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4755.1194036771@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: Bruce M Simpson , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 21:56:30 -0000 * Poul-Henning Kamp [071102 13:53] wrote: > In message <20071102203803.GO77844@elvis.mu.org>, Alfred Perlstein writes: > > >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. > > I don't know if this is realistically possible, without some > kind of intermediate layer to translate, for instance inline > assembly. > > But apart from it being a lot of, currently, pointless work that > would really gain us anything, as long as no viable competitors to > GCC exists, I fully agree: Either you take portability seriously > (ie: run with any compiler) or you handle portability seriously > (ie: run it through our frontend, so any compiler can cope). > > But in any case, this is all very theoretical until there are > a non-comical alternative compiler for us. I really don't understand what you're saying here. All I'm saying is that if we choose to "support" C++ (or any other language), we can come to a compromise where core code does not depend on it, at least for some timeframe so as to ease people's fears. I would honestly hate to see anything added and within a week or a month there are key systems that _used to work just fine_ retrofitted to depend on said compiler/tool/preprocessor/whatever. Such things need to be vetted through optional components first for a time period to ensure that they are viable and at least somewhat future proof. -- - Alfred Perlstein