From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 21:37:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BB0416A4DA for ; Tue, 11 Jul 2006 21:37:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315CD43D64 for ; Tue, 11 Jul 2006 21:37:53 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id h30so1577432wxd for ; Tue, 11 Jul 2006 14:37:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FVlFJ3+Hn/cn3YayuPTF0g/AU/3cP+xE7kM8d2l1/4zD02dc7R54pOBbljDP1vVOGEK4urVmiVzv++YY5tpM6J1agST1+rrg1bv48m88ovxCNWwpbF8B4jvVK+h1nWeiz+O6+/AfGvP3wF4CvST8vwxiW+h0e+P6h1TLPCUqDGU= Received: by 10.70.80.1 with SMTP id d1mr8172897wxb; Tue, 11 Jul 2006 14:37:52 -0700 (PDT) Received: by 10.70.11.15 with HTTP; Tue, 11 Jul 2006 14:37:52 -0700 (PDT) Message-ID: <3bbf2fe10607111437h6547432fn2887348708df29a4@mail.gmail.com> Date: Tue, 11 Jul 2006 23:37:52 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "mag@intron.ac" In-Reply-To: <1152642474.29859@origin.intron.ac> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <20060711152949.GB1463@merlin.emma.line.org> <1152642474.29859@origin.intron.ac> X-Google-Sender-Auth: 8a4ee785531a3df4 Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:37:58 -0000 2006/7/11, mag@intron.ac : > Why do you all consider importing C++ code to FreeBSD kernel to be so > complicated at the beginning? > > Matthias Andree wrote: > > > (please don't Cc me on list replies; chopping down the Cc list) > > > > On Tue, 11 Jul 2006, mag@intron.ac wrote: > > > >> Just as you said, C++ is more complicated than C. However, without > >> C++ exception and other advanced features, it hasn't brought much > >> complexity to C++ runtime library. Early C++ compiler even translates > >> C++ code into C code before real compilation. > > > > But what's the point of C++ if it is mutilated below minimum standard > > compliance levels so that you can no longer call it C++? > > > > This discussion has been through for other systems such as Linux long > > ago, and it wasn't lack of manpower, but lack of technical feasibility, > > or in other words, what was still useful for a kernel wasn't that much > > different from C any more. C99 already adressed several concerns of C89, > > and ISTR that FreeBSD kernels are C99 code these days. > > > >> We can judge whether a C++ feature can or cannot be imported into FreeBSD > >> kernel by assemble code generated by GNU CC. > > > > Great, make the whole kernel depend on compiler internals. > > Can you imagine a single vendor who'd have interest in hauling so many > > dependencies into their software and handle all the support? I can't. > > Please complain about the portability of runtime library after reading > codes in /usr/src/contrib/libstdc++/libsupc++/. > Are they really so difficult to port? > > > > > Write a C stub and put the rest into userspace where C++ works. > > > >> For example, I think C++ exception handling is really poorly suited for > >> low-level code. > > > > Which chops off one of C++'s legs to stand on. > > Aside from the complexity of implementing C++ exception, in kernel, every > exception must be carefully processed. A simple exception throw may lay > memory leak and unfreed resource allocation. And outer exception catch > is difficult to help inner exception. Even if I have no proof-of-concepts (so maybe somebody can show that this is not fair), if we have setjmp/longjmp in the kernel we can have a correct exception handling mechanism without not great problems. Attilio -- Peace can only be achieved by understanding - A. Einstein