From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 17:41:01 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 EDF2C16A4DF for ; Tue, 11 Jul 2006 17:41:00 +0000 (UTC) (envelope-from nitro@263.net) Received: from smtp.263.net (263.net.cn [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C6B443D5C for ; Tue, 11 Jul 2006 17:40:59 +0000 (GMT) (envelope-from nitro@263.net) Received: from origin.intron.ac (unknown [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id C7846F1840 for ; Wed, 12 Jul 2006 01:40:58 +0800 (CST) X-KSVirus-check: 0 References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <86fyh8zgw8.fsf@xps.des.no> <868xn0z8w9.fsf@xps.des.no> <1152629241.24779@origin.intron.ac> <20060711152231.GB1487@britannica.bec.de> In-Reply-To: <20060711152231.GB1487@britannica.bec.de> From: mag@intron.ac To: Joerg Sonnenberger Date: Wed, 12 Jul 2006 01:40:01 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-Id: <1152639658.28572@origin.intron.ac> 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 17:41:01 -0000 Joerg Sonnenberger wrote: > On Tue, Jul 11, 2006 at 10:45:52PM +0800, 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. > > RTTI, allocation, exceptions and static allocators all add complexity > for the runtime library. If you really want to use C++ for a kernel, you > must likely want to use all of them as well. > >> For example, I think C++ exception handling is really poorly suited for >> low-level code. > > Bullshit. With a proper implementation exceptions add no overhead as > long an exception is not thrown in terms of speed. It does matter > somewhat in terms of code (or better: data) size, but the very same > information is useful to generate much better tracebacks as well. > RTTI is highly useful for debugging and semi-optional consistent checks, > which should not be neglected either. I don't care about the abuse of > explicitly comparing object types etc., but the ability to decide what > exactly a certain object is. Aside from the complexity of C++ exception support, in FreeBSD kernel, every exception must be carefully processed, simple exception throw and catch may lay memory leak and resource non-freeing inside kernel if the programmer fails to pay enough attention. Even if C++ code is carefully written for FreeBSD kernel, outer exception catch is so difficult to help deep inner exception. > >> But the "object model" is still obscure to understand no matter how many >> people all over the world master C++. What's more, can the "object model" >> function really as OpenDarwin's IOKit class model? >> (http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html) > > The kobj implementation has the same feature set as a lightweight C++, > e.g. inheritance and virtual functions. That's basically what IOKit is > using as well. It is not obscure, just a Domain Specific Language. A domain specific language, C function pointer list, software context and other independent kernel functions are obscure enough for FreeBSD newbies. > >> Now, OpenDarwin has owned a C++-based kernel object model. But why >> cannot FreeBSD? > > Because the kernel is C and not many points to incrementally add C++ > have been made, which makes it a worthwhile goal. > > And if you want to complain about redundancy in drivers, carefully look > for differences which often far outweight the common functionality. If there's only small differences, there operations can be packed into a function tunable by some arguments. > > Joerg > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ------------------------------------------------------------------------ From Beijing, China