From owner-freebsd-arch@FreeBSD.ORG Sun Oct 28 00:27:43 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 CA2F916A46E for ; Sun, 28 Oct 2007 00:27:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 619A413C4CB for ; Sun, 28 Oct 2007 00:27:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 5145 invoked by uid 399); 28 Oct 2007 00:01:03 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 28 Oct 2007 00:01:03 -0000 X-Originating-IP: 127.0.0.1 Date: Sat, 27 Oct 2007 17:01:02 -0700 (PDT) From: Doug Barton To: Bruce M Simpson In-Reply-To: <472317D7.8010406@incunabulum.net> Message-ID: References: <12773.1193480527@critter.freebsd.dk> <472317D7.8010406@incunabulum.net> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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: Sun, 28 Oct 2007 00:27:43 -0000 On Sat, 27 Oct 2007, Bruce M Simpson wrote: > I should point out that I am not recommending the habitual use of C++ for > FreeBSD kernel development, I have no dog in this hunt, so I'm not commenting on the issue of C++ in the kernel. I would like to comment however on the meta-issue that it doesn't really matter what your intentions are, once you open that door it's open, and it's got to stay open forever. >From an architectural perspective there would have to be an overwhelming benefit to doing this that would far exceed the _known_ costs, never mind adding a few points for the costs we don't know about yet. > nor am I condoning that we accept C++ code into the tree without any > *less* consideration than might be the case for contributions in other > languages (usually C). Well I think that goes without saying, but for the sake of clarity it's probably good that you said it anyway. :) It does raise another issue though, how many kernel developers do we currently have that are willing/able to judge the quality of C++ code? Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Sun Oct 28 05:18:57 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 272CE16A419 for ; Sun, 28 Oct 2007 05:18:57 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate4.pacific.net.sg (smtpgate4.pacific.net.sg [203.81.36.24]) by mx1.freebsd.org (Postfix) with SMTP id 2517C13C491 for ; Sun, 28 Oct 2007 05:18:55 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 27610 invoked from network); 28 Oct 2007 04:52:14 -0000 Received: from bb121-7-30-108.singnet.com.sg (HELO P2120.somewherefaraway.com) (oceanare@121.7.30.108) by smtpgate4.pacific.net.sg with ESMTPA; 28 Oct 2007 04:52:12 -0000 Message-ID: <47241574.6030402@pacific.net.sg> Date: Sun, 28 Oct 2007 12:52:04 +0800 From: Erich Dollansky User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: Bruce M Simpson References: <4722BDBE.5030408@incunabulum.net> In-Reply-To: <4722BDBE.5030408@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sun, 28 Oct 2007 05:18:57 -0000 Hi, Bruce M Simpson wrote: > I was wondering if anyone had done any further thinking about this. let me put it into very simple words. From my experience using C since the late Seventies for very different software projects, I would never use C++ inside a kernel. But I encourage object orientated programming and the use of much more macros to make object orientated programming easier without using C++. A kernel should be small and its response should be predictable in all cases and at all times. This is something which is not always the case with C++. Erich > > It seems a team in Iceland succeeded in making Linux C++ enabled: > http://netlab.ru.is/exception/LinuxCXX.shtml > > Particularly interesting are the measurements for exception handling. > > The Click Modular Router is an example of a test case for C++ in both > the Linux and FreeBSD kernels. > > regards, > BMS > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Sun Oct 28 06:03:09 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 3207016A420 for ; Sun, 28 Oct 2007 06:03:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E790813C48D for ; Sun, 28 Oct 2007 06:03:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id l9S626oP099874; Sun, 28 Oct 2007 00:02:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 28 Oct 2007 00:03:00 -0600 (MDT) Message-Id: <20071028.000300.-861062412.imp@bsdimp.com> To: bms@incunabulum.net From: "M. Warner Losh" In-Reply-To: <4722BDBE.5030408@incunabulum.net> References: <4722BDBE.5030408@incunabulum.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: 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: Sun, 28 Oct 2007 06:03:09 -0000 In message: <4722BDBE.5030408@incunabulum.net> Bruce M Simpson writes: : It seems a team in Iceland succeeded in making Linux C++ enabled: Most people on this list haven't had experience with eC++. In this environment, a number of the features of the language are omitted to be better suited to the embedded environment. If it were up to me, I wouldn't bother with supporting exception. They are one of the areas that are abused that have dire consequences when abused (uncaught exceptions are evil, for example). Rtti was also omitted from eC++ as well. These things help debloat the language and can be used to good effect. The kernel isn't a general purpose computing environment. However, C++ features would help in a great many cases. There's already some C++ elements in kobj, which help us in our implementation of newbus. However, as time passes, more and more things are written in other languages, including C++. Many of these other languages are totally unsuitable for the kernel. Python, Ruby and Perl, while great scripting languages, will never be in the kernel. The old vmkernel.el joke will never happen either (although there's been rumors of an in-kernel compiled-lisp interprater floating around). C++ support, driven by people's experience with OS X, will continue to be a highly desired feature. At this stage, I think if someone came forward with patches, that could be optionally installed, there would be support for including them. Maybe installed as a port. There's been little to no support for integrating C++ into the kernel for general use by the base system, so new C++ drivers or subsystems would meet extreme resistance. However, having C++ support would allow the extreme FreeBSD users to suffer or benefit from C++ in their kernels without having to reinvent the base wheel. I think the arguments are strong enough for this, but not so strong as to accept it into the base at this time without some compelling proof that it can be done, in FreeBSD, without extreme pain. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Oct 28 07:43:11 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 5BD8C16A419 for ; Sun, 28 Oct 2007 07:43:11 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 41F4513C4B5 for ; Sun, 28 Oct 2007 07:43:11 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 233895B3E; Sun, 28 Oct 2007 00:43:10 -0700 (PDT) To: "M. Warner Losh" In-reply-to: Your message of "Sun, 28 Oct 2007 00:03:00 MDT." <20071028.000300.-861062412.imp@bsdimp.com> Date: Sun, 28 Oct 2007 00:43:09 -0700 From: Bakul Shah Message-Id: <20071028074310.233895B3E@mail.bitblocks.com> Cc: bms@incunabulum.net, 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: Sun, 28 Oct 2007 07:43:11 -0000 > scripting languages, will never be in the kernel. The old vmkernel.el > joke will never happen either (although there's been rumors of an > in-kernel compiled-lisp interprater floating around). C++ support, > driven by people's experience with OS X, will continue to be a highly > desired feature. Are you thinking of Bill Bland's Schemix for linux? $ echo '(+ 1 2 3)' > /dev/schemix $ cat /dev/schemix 6 $ echo '(define foo (kernel-lambda (char*) printk))' > /dev/schemix $ echo '(foo blah blah blah)' >/dev/schemix $ dmesg |tail -1 blah blah blah Speaking of vmkernel.el do you know about Movitz (Commom Lisp on bare metal)? Of course, this has nothing to do with why people want C++ in kernel! > However, having C++ support would allow the extreme > FreeBSD users to suffer or benefit from C++ in their kernels without > having to reinvent the base wheel. I think the arguments are strong > enough for this, but not so strong as to accept it into the base at > this time without some compelling proof that it can be done, in > FreeBSD, without extreme pain. 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. How long before people clamor for things like TailQ mount_list; TailQ::iterator mp; for(mp = mount_list.begin(); mp != mount_list.end(); mp+) { ... } From owner-freebsd-arch@FreeBSD.ORG Sun Oct 28 07:46:54 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 B4DDA16A419 for ; Sun, 28 Oct 2007 07:46:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7547A13C4A3 for ; Sun, 28 Oct 2007 07:46:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id DF04617104; Sun, 28 Oct 2007 07:46:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9S7kpNN023409; Sun, 28 Oct 2007 07:46:51 GMT (envelope-from phk@critter.freebsd.dk) To: Bakul Shah From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 28 Oct 2007 00:43:09 MST." <20071028074310.233895B3E@mail.bitblocks.com> Date: Sun, 28 Oct 2007 07:46:50 +0000 Message-ID: <23408.1193557610@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: bms@incunabulum.net, 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: Sun, 28 Oct 2007 07:46:54 -0000 In message <20071028074310.233895B3E@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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 29 17:18:56 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 D61A816A417 for ; Mon, 29 Oct 2007 17:18:56 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C68F13C481 for ; Mon, 29 Oct 2007 17:18:46 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ImRZv-0001JL-50 for freebsd-arch@freebsd.org; Mon, 29 Oct 2007 10:10:39 +0000 Received: from dhcp-69-07.cc.fer.hr ([161.53.69.167]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Oct 2007 10:10:39 +0000 Received: from ivoras by dhcp-69-07.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Oct 2007 10:10:39 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 29 Oct 2007 11:12:36 +0100 Lines: 18 Message-ID: References: <20071028074310.233895B3E@mail.bitblocks.com> <23408.1193557610@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dhcp-69-07.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <23408.1193557610@critter.freebsd.dk> Sender: news 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: Mon, 29 Oct 2007 17:18:56 -0000 Poul-Henning Kamp wrote: > In message <20071028074310.233895B3E@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. A bit of the "NIH syndrome" here? :) > The other main argument is that we can then teach the language to > do the things we need it to do. The less people know the language, the less it will be used. A "one-off" language (like "K") applicable only for FreeBSD is not exactly doomed to popularity. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 29 21:22:26 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 5445116A474 for ; Mon, 29 Oct 2007 21:22:26 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F27B913C4CB for ; Mon, 29 Oct 2007 21:22:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C38FD17105; Mon, 29 Oct 2007 20:22:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9TKMML5033677; Mon, 29 Oct 2007 20:22:23 GMT (envelope-from phk@critter.freebsd.dk) To: Ivan Voras From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 29 Oct 2007 11:12:36 +0100." Date: Mon, 29 Oct 2007 20:22:22 +0000 Message-ID: <33676.1193689342@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: 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: Mon, 29 Oct 2007 21:22:26 -0000 In message , Ivan Voras writes: >Poul-Henning Kamp wrote: >> In message <20071028074310.233895B3E@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. > >A bit of the "NIH syndrome" here? :) Not really. I've personally bugged Bjarne about making C++ usable for systems programming ever since 1987 or so, but to no avail. If you look at kernel code, you will find that the kind of things we do there, are slightly but importantly different from what C++ and other more modern languages are built to handle. For instance, the entire "dual-address space" dictomy og system calls/copy{in,out} and the very concept of interrupts are very tricky to sensibly express in anything but C. So what I've been tinkering with, is not a new language, but a C dialect enhanced to make kernel programming simpler. >> The other main argument is that we can then teach the language to >> do the things we need it to do. > >The less people know the language, the less it will be used. A "one-off" >language (like "K") applicable only for FreeBSD is not exactly doomed to >popularity. I'm not trying to come up with a language to end all languages, I leave that for greater minds than mine. All I want is a compiler and a language that makes it easy for me to write bugfree, efficient and readable kernel code. One thing that particularly bothers me, is that compilers offer no assistance in debugging, because normal programming runs in the UNIX virtual machine, attaching a debugger is the preferred way. In the kernel we don't have that luxury, and there are a number of ways the compiler could help us. Imagine for instance an option to zap the heap with 0xdeadcode on function return or an option to check all function pointers for non-null-ness before jumping through them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 29 21:49:47 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 29E5B16A419 for ; Mon, 29 Oct 2007 21:49:47 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.freebsd.org (Postfix) with ESMTP id E0EF313C4BE for ; Mon, 29 Oct 2007 21:49:46 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l9TKYIFG014352; Mon, 29 Oct 2007 16:34:20 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <23408.1193557610@critter.freebsd.dk> References: <23408.1193557610@critter.freebsd.dk> Date: Mon, 29 Oct 2007 16:34:17 -0400 To: "Poul-Henning Kamp" , Bakul Shah From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Cc: 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: Mon, 29 Oct 2007 21:49:47 -0000 At 7:46 AM +0000 10/28/07, Poul-Henning Kamp wrote: >In message <20071028074310.233895B3E@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) -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Mon Oct 29 23:30:15 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 CA4B816A417 for ; Mon, 29 Oct 2007 23:30:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD7E13C48E for ; Mon, 29 Oct 2007 23:30:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1506869rvb for ; Mon, 29 Oct 2007 16:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received: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; bh=NCKCbzsju5rZsbk60mUEFMqf07xpF19ZmOfIKOZGN3k=; b=gUXizJm8bKBoXBkJpqr8jRm/9D0sKXfZ8sCNvmF5VWOA3AggN5ZGuBr3BERLbnsefVEuLUIk5RQPMpI8pZkYDxPzgn7VaQ2Iq+aAqxDV993m1DV2cCGjhPOgHLm6TYT+PID05oUjPaOfM2JN6J3GskJvWHriXS8wDX5cfNGAbnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; 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=dW74YJYPnF0dJeF0E9YhkAF8jXi3p3Mo/YnTPR35tcy1oh4IfMco8NxO/Kwl7XrRcu5XeN24JpSsiq9EWC2j8G0Tb7W6LNcmQAFf/BuAhYI7dCKG9j2rbt3W/qPOulVXa6bWU3Y/bzs8ySkg3rb/5p+GGO10f0sC6ZR9vtTAxyU= Received: by 10.141.154.5 with SMTP id g5mr3062188rvo.1193698845129; Mon, 29 Oct 2007 16:00:45 -0700 (PDT) Received: by 10.141.194.16 with HTTP; Mon, 29 Oct 2007 16:00:45 -0700 (PDT) Message-ID: <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> Date: Tue, 30 Oct 2007 00:00:45 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <33676.1193689342@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <33676.1193689342@critter.freebsd.dk> X-Google-Sender-Auth: 37672dd831a37668 Cc: 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: Mon, 29 Oct 2007 23:30:15 -0000 On 29/10/2007, Poul-Henning Kamp wrote: > For instance, the entire "dual-address space" dictomy og system > calls/copy{in,out} and the very concept of interrupts are very > tricky to sensibly express in anything but C. I don't see those example as something special or different - they are just "there" to implement with or around. Copyin/out can be implemented as-is, literally in C, or it can be abstracted (and C++ isn't a good candidate for this, AFAIK it lacks proper "properties" - members that cause function invocations in the form of getters/setters - see Object Pascal, C#, Python, etc.). On the lowest level, interrupts are just function invocations triggered externally, by hardware. Any language that can give you a pointer to a function can handle those. There is no reason not to implement the kernel in e.g. Pascal (if would even give us some of the features you want: string and array bounds checking) though C might be more efficient because it's closer to the metal. > So what I've been tinkering with, is not a new language, but a > C dialect enhanced to make kernel programming simpler. That's my point: another nonstandard dialect of C, no matter how useful, will only alienate new people from joining the project. A subset of C++ will not. >an option to check all function pointers for > non-null-ness before jumping through them. At compile time or at runtime? :) At compile time it's practically impossible in C, at runtime, the only thing you could reasonably do is panic, which doesn't gain you anything... I'd rather go for some kind of transparent debugging infrastructure (even if it means patches to the compiler), like malloc debuggers in userland or garbage collectors, which keep the language pretty much intact and standard. These are just my opinions, I haven't designed any OSes lately :) From owner-freebsd-arch@FreeBSD.ORG Mon Oct 29 23:52:22 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 94EBB16A420 for ; Mon, 29 Oct 2007 23:52:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A22C213C494 for ; Mon, 29 Oct 2007 23:52:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8C65A17107; Mon, 29 Oct 2007 21:52:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9TLqjJ7033999; Mon, 29 Oct 2007 21:52:45 GMT (envelope-from phk@critter.freebsd.dk) To: Garance A Drosehn From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 29 Oct 2007 16:34:17 -0400." Date: Mon, 29 Oct 2007 21:52:45 +0000 Message-ID: <33998.1193694765@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: 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: Mon, 29 Oct 2007 23:52:22 -0000 In message , Garance A Drosehn writes: >I've been meaning to look into D [...] The first requirement for any new language, is that it is able to compile our current sources, and preferably adding a benefit while doing so (better diagnostics, style(9) warnings or similar) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 05:58:54 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 C2A9F16A418 for ; Tue, 30 Oct 2007 05:58:54 +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 9E8EE13C4B5 for ; Tue, 30 Oct 2007 05:58:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 850611A4D84; Mon, 29 Oct 2007 22:58:40 -0700 (PDT) Date: Mon, 29 Oct 2007 22:58:40 -0700 From: Alfred Perlstein To: Garance A Drosehn Message-ID: <20071030055840.GS33488@elvis.mu.org> References: <23408.1193557610@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Poul-Henning Kamp , 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: Tue, 30 Oct 2007 05:58:54 -0000 * Garance A Drosehn [071029 22:50] wrote: > At 7:46 AM +0000 10/28/07, Poul-Henning Kamp wrote: > >In message <20071028074310.233895B3E@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 From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 07:03:55 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 DD69F16A417; Tue, 30 Oct 2007 07:03:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9D913C491; Tue, 30 Oct 2007 07:03:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5DD2617104; Tue, 30 Oct 2007 07:03:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9U73Upd035773; Tue, 30 Oct 2007 07:03:30 GMT (envelope-from phk@critter.freebsd.dk) To: "Ivan Voras" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 30 Oct 2007 00:00:45 +0100." <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> Date: Tue, 30 Oct 2007 07:03:30 +0000 Message-ID: <35772.1193727810@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: 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: Tue, 30 Oct 2007 07:03:55 -0000 In message <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com>, "Ivan Voras" writes: >On 29/10/2007, Poul-Henning Kamp wrote: >> For instance, the entire "dual-address space" dictomy og system >> calls/copy{in,out} and the very concept of interrupts are very >> tricky to sensibly express in anything but C. > >I don't see those example as something special or different - they are >just "there" to implement with or around. You don't get my point obviously. I'm not talking about "being able to", I'm talking about "being able to improve the quality of". You're totally right that C++ doesn't help in any way, and that is exactly my point, I want help from the compiler, not hindrance. >> So what I've been tinkering with, is not a new language, but a >> C dialect enhanced to make kernel programming simpler. > >That's my point: another nonstandard dialect of C, no matter how >useful, will only alienate new people from joining the project. A >subset of C++ will not. I suspect that C++ might alienate a number of current developers :-) >>an option to check all function pointers for >> non-null-ness before jumping through them. > >At compile time or at runtime? :) At compile time it's practically >impossible in C, at runtime, the only thing you could reasonably do is >panic, which doesn't gain you anything... A panic gains you a lot, if it happens before the function pointer call hoses you, rather than after, when you cannot get a backtrace. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 07:18:34 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 16D7416A49C; Tue, 30 Oct 2007 07:18:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A06C713C4C2; Tue, 30 Oct 2007 07:18:33 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 32D9F17104; Tue, 30 Oct 2007 07:18:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9U7I9xY035923; Tue, 30 Oct 2007 07:18:09 GMT (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 29 Oct 2007 22:58:40 MST." <20071030055840.GS33488@elvis.mu.org> Date: Tue, 30 Oct 2007 07:18:09 +0000 Message-ID: <35922.1193728689@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Garance A Drosehn , 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: Tue, 30 Oct 2007 07:18:34 -0000 In message <20071030055840.GS33488@elvis.mu.org>, Alfred Perlstein writes: >I think the right thing to do here is to identify the things we >need added to C++ and propose those to the standards. Been there, done that, no chance in hell (see other email for examples). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 10:46:10 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 B522316A420 for ; Tue, 30 Oct 2007 10:46:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id D6E6D13C4B2 for ; Tue, 30 Oct 2007 10:46:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l9UAjtDK006371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 21:45:56 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9UAjt43057638; Tue, 30 Oct 2007 21:45:55 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9UAjs4x057637; Tue, 30 Oct 2007 21:45:54 +1100 (EST) (envelope-from peter) Date: Tue, 30 Oct 2007 21:45:54 +1100 From: Peter Jeremy To: Ivan Voras Message-ID: <20071030104554.GZ70883@server.vk2pj.dyndns.org> References: <33676.1193689342@critter.freebsd.dk> <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zBPbvmIlJjvpbu6L" Content-Disposition: inline In-Reply-To: <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Poul-Henning Kamp , 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: Tue, 30 Oct 2007 10:46:10 -0000 --zBPbvmIlJjvpbu6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2007 at 12:00:45AM +0100, Ivan Voras wrote: >handle those. There is no reason not to implement the kernel in e.g. >Pascal (if would even give us some of the features you want: string >and array bounds checking) though C might be more efficient because >it's closer to the metal. Pascal was designed for teaching programming. I don't think it should be used in any production environment. Some of the design decisions (eg no logical short-cutting) make writing real code quite painful. PrimeOS was written in FORTRAN - which I think was stretching the language rather a lot. Multics was written in PL/I. The Modula family were designed for systems programming. >> So what I've been tinkering with, is not a new language, but a >> C dialect enhanced to make kernel programming simpler. > >That's my point: another nonstandard dialect of C, no matter how >useful, will only alienate new people from joining the project. It depends on what Poul-Henning intends by "dialect". I would also be concerned about changing the language by adding new keywords or magic functions that were required to be understood for the code to function correctly. OTOH, extending (eg) the __attribute__ syntax to provide optional guidance to the compiler to let it produce better code and provide better warnings is a good thing - the code is correct with or without the __attribute__ but the compiler has a better idea of what the programmer intended. > A subset of C++ will not. I suspect this will alienate C programmers (because it's not C) as well as C++ programmers (because it's missing their favourite feature). >(even if it means patches to the compiler), I see no reason not to patch the compiler if we can make it generate code and/or warnings that make it easier to locate and/or avoid bugs. --=20 Peter --zBPbvmIlJjvpbu6L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHJwti/opHv/APuIcRAq9IAJwNBFpAn3sJNOhKfU3p9qVSnlpWpgCeIKnV 8ntHvGx3CiK174mj5N52fic= =XVYZ -----END PGP SIGNATURE----- --zBPbvmIlJjvpbu6L-- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 13:48:33 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 8A36716A46C for ; Tue, 30 Oct 2007 13:48:33 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229]) by mx1.freebsd.org (Postfix) with ESMTP id 423B013C4AA for ; Tue, 30 Oct 2007 13:48:32 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1297652nzf for ; Tue, 30 Oct 2007 06:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received: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; bh=GoNS22CxsgniUOMLKGd9Nj5kv70GxrGuQS8rMwIFO+g=; b=ETWyoIcYJwbtjLW3iAYv3rmH0nuMWOAAcacg8ETIT1yOL/Xd91jcg45G2NVZqGSyTrbH5J7uOoJWyhjRl9DbmyUMmeWaaQdxoDQxSBfALjwTY1k05zWtcO/gp5lG8Z0lza5oTw6Iaf/X5imE1CtZoSZajiBXDlHmq/ATnR9Sc2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; 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=ps3BuDg2/a4PEMpC7yyUJm2FMRupxelkxReuFhUO7Q5D+dfogjrbcZT+4nkTXXxRyvl6x7Sotpft0zD5a7Zmu86AESYHzrWbeEsta4pGGMOQec/s4bPLtmhBWU2W3Gd6dCgm2O6KFnM4JUlaL6kCvcETrPDEXapdbB3LbPQ3Yd8= Received: by 10.141.87.13 with SMTP id p13mr3333677rvl.1193752111341; Tue, 30 Oct 2007 06:48:31 -0700 (PDT) Received: by 10.141.194.16 with HTTP; Tue, 30 Oct 2007 06:48:26 -0700 (PDT) Message-ID: <9bbcef730710300648s4a4162a9x25e5a092111eaab9@mail.gmail.com> Date: Tue, 30 Oct 2007 14:48:26 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Peter Jeremy" In-Reply-To: <20071030104554.GZ70883@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <33676.1193689342@critter.freebsd.dk> <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> <20071030104554.GZ70883@server.vk2pj.dyndns.org> X-Google-Sender-Auth: b2e773ad724ae068 Cc: 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: Tue, 30 Oct 2007 13:48:33 -0000 On 30/10/2007, Peter Jeremy wrote: > On Tue, Oct 30, 2007 at 12:00:45AM +0100, Ivan Voras wrote: > >handle those. There is no reason not to implement the kernel in e.g. > >Pascal (if would even give us some of the features you want: string > >and array bounds checking) though C might be more efficient because > >it's closer to the metal. > > Pascal was designed for teaching programming. I don't think it should > be used in any production environment. Some of the design decisions > (eg no logical short-cutting) make writing real code quite painful. > PrimeOS was written in FORTRAN - which I think was stretching the > language rather a lot. Multics was written in PL/I. The Modula > family were designed for systems programming. Of course I'm not suggesting to rewrite the kernel in Pascal (or anything else). > >> So what I've been tinkering with, is not a new language, but a > >> C dialect enhanced to make kernel programming simpler. > > > >That's my point: another nonstandard dialect of C, no matter how > >useful, will only alienate new people from joining the project. > > It depends on what Poul-Henning intends by "dialect". I would also > be concerned about changing the language by adding new keywords or > magic functions that were required to be understood for the code > to function correctly. OTOH, extending (eg) the __attribute__ > syntax to provide optional guidance to the compiler to let it > produce better code and provide better warnings is a good thing - > the code is correct with or without the __attribute__ but the > compiler has a better idea of what the programmer intended. I think the more advanced examples here: http://wiki.freebsd.org/K are sufficiently diverged from C to make them ugly :) > >(even if it means patches to the compiler), > > I see no reason not to patch the compiler if we can make it generate > code and/or warnings that make it easier to locate and/or avoid bugs. I think the context of my quote was in favour of this, as long as the language remains standard. On the other hand, if the goal is to make debugging easier, isn't DTrace going to be "The Way" to do it? From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 14:50:37 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 4F56816A417 for ; Tue, 30 Oct 2007 14:50:37 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx03.syd.optusnet.com.au (fallbackmx03.syd.optusnet.com.au [211.29.133.136]) by mx1.freebsd.org (Postfix) with ESMTP id E343F13C49D for ; Tue, 30 Oct 2007 14:50:35 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx03.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l9U6wPWm013658 for ; Tue, 30 Oct 2007 17:58:37 +1100 Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l9U6w0On010342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 17:58:01 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9U6w0KB056920; Tue, 30 Oct 2007 17:58:00 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9U6vxAG056919; Tue, 30 Oct 2007 17:57:59 +1100 (EST) (envelope-from peter) Date: Tue, 30 Oct 2007 17:57:59 +1100 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20071030065759.GW70883@server.vk2pj.dyndns.org> References: <33676.1193689342@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TxukmIqg3MmZ0Kmh" Content-Disposition: inline In-Reply-To: <33676.1193689342@critter.freebsd.dk> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: 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: Tue, 30 Oct 2007 14:50:37 -0000 --TxukmIqg3MmZ0Kmh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 29, 2007 at 08:22:22PM +0000, Poul-Henning Kamp wrote: >Not really. I've personally bugged Bjarne about making C++ usable >for systems programming ever since 1987 or so, but to no avail. I can also see some benefits in parts of C++ - we already simulate bits of classes, inheritance and templates in the kernel and having a language where this was an integral part of the language should improve code readibility and reduce scope for errors. I also agree that C++ brings with it far too much baggage and allowing a useful subset into the kernel would lead to the rest of the camel following over time. >One thing that particularly bothers me, is that compilers offer >no assistance in debugging, because normal programming runs in the >UNIX virtual machine, attaching a debugger is the preferred way. Virtualisation offers one way of making kernel debugging less painful but I agree that debugging a mis-behaving kernel is much harder than debugging a userland application. >Imagine for instance an option to zap the heap with 0xdeadcode on >function return or an option to check all function pointers for >non-null-ness before jumping through them. Both these should be fairly simple patches to gcc. The former would be useful in application programming as well as kernel programming and could therefore make it back into the vendor gcc. I don't really see the benefit of the latter - calling a NULL function pointer will immediately trap and trigger a panic. For much of the kernel, it's not clear what else to do. Possibly there are some cases where the kernel could take recovery action and continue but that requires much finer control than a compiler switch - it would seem easier (and more efficient) to add code into the trap handler to recover from expected traps (much as copyin() and copyout() do now) than add a conditional test to every call instruction. Note that neither of these imply a change to the language. Maybe, in another thread, you might like to discuss your ideas for what additional features our development toolkit should have to assist with kernel development. --=20 Peter --TxukmIqg3MmZ0Kmh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHJtX3/opHv/APuIcRAvs0AJ9JzTho38qVkDikA4HlzepXJK6JyQCfT/OU DUB2Hqi4zpJvRbuCFPbVXRU= =nzlt -----END PGP SIGNATURE----- --TxukmIqg3MmZ0Kmh-- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 15:40:28 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 C069D16A469 for ; Tue, 30 Oct 2007 15:40:28 +0000 (UTC) (envelope-from prog@msobczak.com) Received: from v045611.home.net.pl (v045611.home.net.pl [89.161.227.145]) by mx1.freebsd.org (Postfix) with SMTP id 1DBBB13C4B7 for ; Tue, 30 Oct 2007 15:40:27 +0000 (UTC) (envelope-from prog@msobczak.com) Received: from localhost (HELO pb-d-128-141-44-124.cern.ch) (prog.msobczak@home@127.0.0.1) by m130.home.net.pl with SMTP; Tue, 30 Oct 2007 15:13:51 -0000 Message-ID: <47274A29.9040801@msobczak.com> Date: Tue, 30 Oct 2007 16:13:45 +0100 From: Maciej Sobczak User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org References: <23408.1193557610@critter.freebsd.dk> <20071030055840.GS33488@elvis.mu.org> In-Reply-To: <20071030055840.GS33488@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Tue, 30 Oct 2007 15:40:28 -0000 Alfred Perlstein wrote: (I reply also to some previous mail which I didn't get from the list.) >> 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. Do you often change the compiler in the middle of a STABLE branch? If not, then why are you worried about changes in the language? They will not magically propagate to the compiler. Pick the compiler version and stick to it for the whole branch lifetime. >> 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++. Why are you worried about developments that can come up? Do you try to protect yourself from new developments that can come up in C as well? You don't own neither C++, nor 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. Sorry to say this, but is it worthwhile to look into every single language which you have no experience with? That might get long. > I think the right thing to do here is to identify the things we > need added to C++ and propose those to the standards. I think you got it completely backwards. First a bit of context - the C++ standard committee is already in deep sht^H^H^Hwork to get the current proposals straight and ship the new standard revision, which is already late. No new proposals are accepted, unless they save the world. Considering the usual rythm of standardization process, the next chance to add anything to C++ will be at the end of the next decade. FreeBSD might be already dead till that time with Linux overtaking whatever is left from the community. You should reverse your thinking and instead ask yourself: what parts and elements of *current* C++ might be useful for kernel development? If you identify them you can actually benefit from adapting them. If not, abandon the idea altogether and continue the current way. If you try to do anything else, you will only waste resources. Actually, C++ is being used in embedded and real-time systems as well as for signal processing, so apparently there *are* some communities that already gained experience with constrained use of the language. Presumably some of the constraints that these people face are also valid in the kernel world, and presumably some of the solutions might be successfully reused. Don't reinvent! And don't disperse your energy on exploring anything exotic like Yet Another Language That Nobody Heard About (tm). This is doomed. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 16:36:15 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 2664116A419; Tue, 30 Oct 2007 16:36:15 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7FACC13C4A7; Tue, 30 Oct 2007 16:36:14 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id E70665B30; Tue, 30 Oct 2007 09:36:13 -0700 (PDT) To: Alfred Perlstein In-reply-to: Your message of "Mon, 29 Oct 2007 22:58:40 PDT." <20071030055840.GS33488@elvis.mu.org> Date: Tue, 30 Oct 2007 09:36:13 -0700 From: Bakul Shah Message-Id: <20071030163613.E70665B30@mail.bitblocks.com> Cc: Poul-Henning Kamp , Garance A Drosehn , 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: Tue, 30 Oct 2007 16:36:15 -0000 Alfred Perlstein wrote: > * Garance A Drosehn [071029 22:50] wrote: > > ... > > 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 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. Listing what is needed seems like a good first step (though I don't know about C++). I don't know rolling one's own extensions is a good idea either but a discussion of needs can help in figuring out the right thing to do and provide a strong rationale for whichever solutions are chosen. Without identifying needs we will end up talking at cross purposes. These can be along several axes: - better debugging support - better profiling - better testing (code coverage etc.) - better runtime checking (e.g. null checking, assertions) - better static checking (e.g. coverity?) - support for better abstractions (e.g. critical sections, "objects") - better support for SMP ... I am *not* suggesting coming up with something that covers all of the above; this is just a way of classifying so that they can be evaluated in the context of given constraints. It may turn out that several different solutions will exist apart from any language extensions. For instance, rather than enhancing the language can one come up with a better structure (or design pattern) for a part of the OS? Can a transparent filter add code to implement something we want (for instance, code coverage)? Can one generate low level tests automatically from header or code files? Can code be generated automatically to enable heavy assertion checking on first signs of trouble but otherwise let the kernel run at fullspeed? Sort of like airbags that deploy on first impact! Is there a more detailed writeup of Poul's ideas on K language beyond what is on the wiki.freebsd.org/K? Reading it brings to mind Brinch Hansen's extensions to Pascal. The structured macro paper referenced on the K wiki page also seems rather interesting. A powerful macro facility needs to be well integrated with the language (much like Lisp or Scheme's macros) so that you can write for instance critical_section(lock) { ... bar: ... if (cond1) break; ... if (cond2) goto foo; ... if (cond3) goto bar; ... if (cond4) return; // from enclosing function ... } ... foo: and have it transform to vanilla C code that does proper unlocking on any exit. To a first approximation I think of them as compile time "functions" that take identifiers and code as arguments and return code. IMHO building in things like mutexes or critical region etc. in a language makes it far too special purpose and both the code & compiler less portable (if the low level code for a critical section needs to be different for a different architecture, you have to change the compiler). But a general purpose macro facility can allow you to build these and many other kinds of control abstractions and hence is more likely to be popular if done right. Coming up with something that is semantically well defined & integrates well with C can not be easy. All budding feature designers ought to read Tony Hoare's "Hints on programming language design". Still relevant after 33 years. Search for cb-p193-hoare.pdf. -- bakul From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 17:14:42 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 C8B9B16A420; Tue, 30 Oct 2007 17:14:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4D75D13C4B8; Tue, 30 Oct 2007 17:14:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C47C017104; Tue, 30 Oct 2007 17:14:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9UHEcrn001822; Tue, 30 Oct 2007 17:14:39 GMT (envelope-from phk@critter.freebsd.dk) To: Bakul Shah From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 30 Oct 2007 09:36:13 MST." <20071030163613.E70665B30@mail.bitblocks.com> Date: Tue, 30 Oct 2007 17:14:38 +0000 Message-ID: <1821.1193764478@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Alfred Perlstein , Garance A Drosehn , 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: Tue, 30 Oct 2007 17:14:43 -0000 In message <20071030163613.E70665B30@mail.bitblocks.com>, Bakul Shah writes: >Is there a more detailed writeup of Poul's ideas on K >language beyond what is on the wiki.freebsd.org/K? Reading >it brings to mind Brinch Hansen's extensions to Pascal. Knowing that I may regret this, here is my private notes file on K syntax extensions. Preprocessor shell escape ------------------------- #! { ident } ident Generate C/K source with external program. Can be used to generate tables or include firmware files directly from the binary. Public/Private structs ---------------------- public struct foo { ... } Has sizeof() = -1, cannot be assigned. private struct foo { ... } Adds fields to the public struct foo, has sizeof the joint size. Acts like normal struct. Bitmaps ------- bitmap foo { bar, barf, ...}; Like enum, but assigns bit values and allows logical operations. Style/Syntax checks ------------------- Flag misindentation: if (some_cond) do_this(foo); and_that(bar); Style(9) warnings Macros taking code as argument ------------------------------ #define LOCK(a, {}) do { mtx_lock(&a); __CODE__ mtx_unlock(&a); } while (0); XXX: what happens on return/break/etc ? #define LOCK(a, {}) __CODE__( entry { mtx_lock(&a); } return { mtx_unlock(&a); } ) XXX: not happy about syntax Pointer colors -------------- void * "userland" ptr; Cannot be used as regular void *, but must be passed to functions which has same color prototype. Integer ranges -------------- int foo [21...45]; or int foo range [21...45]; Integer endianess ----------------- uint32_t big_endian foo; Atomic variables ---------------- uint32_t atomic foo; Struct offsets and sizes ------------------------ struct foo { sizeof 128; big_endian; align 16; uint8_t foo @0; uint32_t little_endian bar @12; } Multi-loop break ---------------- if (foo != NULL) { TAILQ_FOREACH(foo, &bar, list) { if (foo->idx == idx) break(2); } panic("not found"); } Call identification ------------------- int foo(int barf, void *there, private void **id); The "id" argument points to a call specific, globally unique, static instance of the pointed to type. This can be used for instance to cache a function pointer for lazy binding (KOBJ ?) Alternatively, even faster, go the full length and make run-time resolved function pointers (trouble hunting them down at modunload ?) Sensible jump prediction ------------------------ TAILQ_FOREACH(foo, &bar, list) {{ do_this_alot(foo); }} #include pointlessness warnings ------------------------------- Warn about #includes that have no effect Cross-Referencing ----------------- Generate cross-reference data on joint preproc/C/K level. Function instantiation by prototype ----------------------------------- typedef int foo_f(int arg, void *priv, struct *obj); static foo_f thisfunc(.) { if (arg) { ... } } Argument struct/array building ------------------------------ int foo(struct timeval tv); int bar(int someargs) { foo({.tv_sec = someargs}); } Compile time debugging aids --------------------------- * Look out for 0xdeadc0de+/-256 Check any pointer dereference against the indicated interval * Struct */void * typecheck Give each struct a magic identifier, check after void* transport. * Struct canary insertion Insert canary elements in struct and check their magic values whenever neighbouring elements are tweaked. * Assignment code insertion Insert code "foo" whenever variable "bar" is assigned or changed. Typical values of "foo" would be "mtx_assert_locked(...)" replacement ------------------------- list_head(struct foo, ...) foolist; possible options: single Single linked list double Double linked list tail Tail is accessible from head head Head is accessible from elem member Only allow use with member in target struct. struct foo { list_member list; list_member(opts...) list2; }; list_empty(head) list_next(elem) list_prev(elem) list_first(head) list_last(head) list_insert_head(elem, head) list_insert_tail(elem, tail) list_insert_before(elem, elem {,head ?}) list_insert_after(elem, elem {,head ?}) list_remove(elem {,head ?}) list_init_head(head) list_take_first(head) list_take_last(head) list_foreach(elem, head {,member}) list_foreach_safe(elem, head {,member}) list_foreach_reverse(elem, head {,member}) list_foreach_reverse_safe(elem, head {,member}) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 17:37:36 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 581CA16A46C; Tue, 30 Oct 2007 17:37:36 +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 11D4B13C4B0; Tue, 30 Oct 2007 17:37:35 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1135D1A4D84; Tue, 30 Oct 2007 10:37:35 -0700 (PDT) Date: Tue, 30 Oct 2007 10:37:35 -0700 From: Alfred Perlstein To: Bakul Shah Message-ID: <20071030173734.GV33488@elvis.mu.org> References: <20071030055840.GS33488@elvis.mu.org> <20071030163613.E70665B30@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071030163613.E70665B30@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i Cc: Poul-Henning Kamp , Garance A Drosehn , 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: Tue, 30 Oct 2007 17:37:36 -0000 * Bakul Shah [071030 09:36] wrote: > > The structured macro paper referenced on the K wiki page also > seems rather interesting. A powerful macro facility needs to > be well integrated with the language (much like Lisp or > Scheme's macros) so that you can write for instance > > critical_section(lock) { > ... > bar: > ... > if (cond1) break; > ... > if (cond2) goto foo; > ... > if (cond3) goto bar; > ... > if (cond4) return; // from enclosing function > ... > } > ... > foo: do you mean like C++: do { critical_object critical_instance(); } ? Just wondering how much of this we want to roll on on our own. -Alfred From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 17:37:41 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 BEC1616A46B for ; Tue, 30 Oct 2007 17:37:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id A17E813C4B7 for ; Tue, 30 Oct 2007 17:37:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 30 Oct 2007 10:37:40 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 2FFCA126884; Tue, 30 Oct 2007 10:37:40 -0700 (PDT) Message-ID: <47276C05.4030506@elischer.org> Date: Tue, 30 Oct 2007 10:38:13 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Poul-Henning Kamp References: <33676.1193689342@critter.freebsd.dk> In-Reply-To: <33676.1193689342@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ivan Voras , 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: Tue, 30 Oct 2007 17:37:41 -0000 Poul-Henning Kamp wrote: > In message , Ivan Voras writes: > > For instance, the entire "dual-address space" dictomy og system > calls/copy{in,out} and the very concept of interrupts are very > tricky to sensibly express in anything but C. > > So what I've been tinkering with, is not a new language, but a > C dialect enhanced to make kernel programming simpler. I've also been doing some mental tinkering with the idea of a language specifically designed for the kernel. "But that was what C was designed for" I hear you say. Yes, but that was 30 years ago (hmmm actually 35 or so since C was introduced I think). There are a lot of things we do in the kernel that could do with abstracting. Really if you look at it, there are some special addressing requirements such as those phk points to.. knowledge of physical space, kernel space and the user space abstraction. There are also lots of locking requirements that might be hidden, and the ability to cope with kernel modules might be something that we may be able to build in. I sometimes wonder if there isn't a room for a language where you can specify more what you want out of it than how to do it. Most of the kernel is composed of about 30 different CS101 algorithms. hash tables linked lists chained buffers a couple of locking primatives event handlers method tables 'items' linked in to multiple lists (e.g. LRU+hash etc) etc. if you could abstract out most of these you might be able to specify the behaviour you want and let the language take care of the details.. for (a random, trivial) example, threads are linked off processes. they are cached. they have a stack associated with them. There is hand written code to take care of this but given the following specification, all that could be automated. 0/ there is a 1 to many direct correlation between "processes" (defined elsewhere) and threads 1/ threads are iteratable from the process. 2/ a thread can find its process easily. 3/ threads can be added or removed from a process 4/ threads can sometimes need to be locked from changes 5/ a thread is associated with a context (by which I mean there is a context from which a thread structure is 'special'. i.e. curthread points to it. 6/ threads need to be allocated and freed. 7/ allocation time can be critical. given the above, any of us could possibly write the linkage code blindfolded. So, why should we write it at all? From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 18:11:25 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 88C8416A420; Tue, 30 Oct 2007 18:11:25 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 6047A13C4DD; Tue, 30 Oct 2007 18:11:25 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id EC35B5B30; Tue, 30 Oct 2007 11:11:24 -0700 (PDT) To: Alfred Perlstein In-reply-to: Your message of "Tue, 30 Oct 2007 10:37:35 PDT." <20071030173734.GV33488@elvis.mu.org> Date: Tue, 30 Oct 2007 11:11:24 -0700 From: Bakul Shah Message-Id: <20071030181124.EC35B5B30@mail.bitblocks.com> Cc: Poul-Henning Kamp , Garance A Drosehn , 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: Tue, 30 Oct 2007 18:11:25 -0000 > * Bakul Shah [071030 09:36] wrote: > > > > The structured macro paper referenced on the K wiki page also > > seems rather interesting. A powerful macro facility needs to > > be well integrated with the language (much like Lisp or > > Scheme's macros) so that you can write for instance > > > > critical_section(lock) { > > ... > > bar: > > ... > > if (cond1) break; > > ... > > if (cond2) goto foo; > > ... > > if (cond3) goto bar; > > ... > > if (cond4) return; // from enclosing function > > ... > > } > > ... > > foo: > > > do you mean like C++: > > do { > critical_object critical_instance(); > > > > > } No idea but I can not see how that will do what I had in mind. A purely lexical translation of the snippet I gave above would be something like: /* struct mtx lock is a non local object */ { mutex_lock(&lock); ... bar: ... if (cond1) goto _break11; ... if (cond2) goto _foo12; ... if (cond3) goto bar; ... if (cond4) goto _return13; // from enclosing function ... _break11: mutex_unlock(&lock); break; _foo12: mutex_unlock(&lock); goto foo; _return13: mutex_unlock(&lock); return; } ... foo: This as an example of what *I would want* a macro facility to do! Implementing such a facility would not be very hard (after all it is just tree surgery) but coming up with a macro language that is non-ugly is very hard and I do realize that. One level up, this is *one way* to achieve writing error free mutex code. Another is through some sort of static analysis tool. A third is through code walkthroughs. Each has different costs. > Just wondering how much of this we want to roll on on our own. So am I! But it is worth pursuing some of these threads at the discussion level. The more important point is the underlying "need" which we can all agree on (I hope!), which is to be able to write such code in an error free way. If we have such a list we can figure out which ones to focus on and how to satisfy them. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 18:22:56 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 0E92316A417; Tue, 30 Oct 2007 18:22:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id AD4DE13C4A3; Tue, 30 Oct 2007 18:22:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id l9UI0rdp004337; Tue, 30 Oct 2007 11:00:53 -0700 (PDT) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id l9UI0orY028387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2007 11:00:51 -0700 (PDT) Message-Id: <60B5543F-CB5D-4E1C-8F36-5BAE1818D1CE@mac.com> From: Marcel Moolenaar To: Poul-Henning Kamp In-Reply-To: <33676.1193689342@critter.freebsd.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Tue, 30 Oct 2007 11:00:48 -0700 References: <33676.1193689342@critter.freebsd.dk> X-Mailer: Apple Mail (2.912) Cc: Ivan Voras , 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: Tue, 30 Oct 2007 18:22:56 -0000 On Oct 29, 2007, at 1:22 PM, Poul-Henning Kamp wrote: > For instance, the entire "dual-address space" dictomy og system > calls/copy{in,out} and the very concept of interrupts are very > tricky to sensibly express in anything but C. Serialization and multi-threading is another thing that cannot be expressed in or isn't part of the language and as such a possible cause for bugs. Those bugs are the result of invalid compiler optimizations -- that is valid in the normal case, but invalid related to locking or multi-threading. Think for example about common sub-expression elimination (CSE) in the context of: lock() a1 = x ... x = a2 unlock() ... lock() b1 = x ... x = b2 unlock() If the compiler knows that lock() and unlock() cannot change the value of x (by virtue of making lock() and unlock() pure and side-effect free) then it may end up generating: c = x ... lock() a1 = c ... x = a2 unlock() ... lock() b1 = c ... x = b2 unlock() Now we have a reference to x that's not protected by the lock and doesn't take multi-threading into account (i.e. the second load cannot be eliminated because x may have changed) and may result in runtime failures. Making x volatile is just a pessimization because that prevents valid CSE operations. See also: Hans Boehm, Reordering constraints for pthread-style locks, ACM SIGPLAN, 2007 http://portal.acm.org/citation.cfm?id=1229470 -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 20:12: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 26F1F16A419; Tue, 30 Oct 2007 20:12: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 1648E13C481; Tue, 30 Oct 2007 20:12:29 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 8D0661A4D81; Tue, 30 Oct 2007 13:12:29 -0700 (PDT) Date: Tue, 30 Oct 2007 13:12:29 -0700 From: Alfred Perlstein To: Bakul Shah Message-ID: <20071030201229.GA33488@elvis.mu.org> References: <20071030173734.GV33488@elvis.mu.org> <20071030181124.EC35B5B30@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071030181124.EC35B5B30@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i Cc: Poul-Henning Kamp , Garance A Drosehn , 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: Tue, 30 Oct 2007 20:12:30 -0000 * Bakul Shah [071030 11:11] wrote: > > * Bakul Shah [071030 09:36] wrote: > > > > > > The structured macro paper referenced on the K wiki page also > > > seems rather interesting. A powerful macro facility needs to > > > be well integrated with the language (much like Lisp or > > > Scheme's macros) so that you can write for instance > > > > > > critical_section(lock) { > > > ... > > > bar: > > > ... > > > if (cond1) break; > > > ... > > > if (cond2) goto foo; > > > ... > > > if (cond3) goto bar; > > > ... > > > if (cond4) return; // from enclosing function > > > ... > > > } > > > ... > > > foo: > > > > > > do you mean like C++: > > > > do { > > critical_object critical_instance(); > > > > > > > > > > } > > No idea but I can not see how that will do what I had in mind. A purely > lexical translation of the snippet I gave above would be something like: You can create an object on the stack that locks the mutex given to it like so: do { mtx_lock_object mtx_locker(&lock); } When the object is destroyed by stack popping, the lock will be freed. It's the same thing. -Alfred From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 21:27:08 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 68AFA16A418; Tue, 30 Oct 2007 21:27:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B731513C4AA; Tue, 30 Oct 2007 21:27:07 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0827417105; Tue, 30 Oct 2007 21:27:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9ULR4w9002980; Tue, 30 Oct 2007 21:27:04 GMT (envelope-from phk@critter.freebsd.dk) To: "Ivan Voras" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 30 Oct 2007 14:48:26 +0100." <9bbcef730710300648s4a4162a9x25e5a092111eaab9@mail.gmail.com> Date: Tue, 30 Oct 2007 21:27:04 +0000 Message-ID: <2979.1193779624@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: 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: Tue, 30 Oct 2007 21:27:08 -0000 In message <9bbcef730710300648s4a4162a9x25e5a092111eaab9@mail.gmail.com>, "Ivan Voras" writes: >I think the more advanced examples here: http://wiki.freebsd.org/K are >sufficiently diverged from C to make them ugly :) That page represents a SoC project which was didn't much suit my taste for language development, but which nontheless was kind of inspiring. >I think the context of my quote was in favour of this, as long as the >language remains standard. But then again, what exactly is "standard" in this context ? C99 ? or style(9) ? We already use a C-diallect, all I'm proposing is giving it more theeth so it can help us. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 22:26: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 B43DA16A49C for ; Tue, 30 Oct 2007 22:26:30 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 5E23013C4BF for ; Tue, 30 Oct 2007 22:26:27 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1775152rvb for ; Tue, 30 Oct 2007 15:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received: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; bh=aFcuwwBUzvZLE66LOXilyy0MHH2ILdnP+/RV31OMoPQ=; b=AuP/2eDVGeb6Iw9qyAmOhUQ4Sg6aNGt9nF5idSouldhHJ7o0GoTeGebWGAZLTArkI6uGlJDQX5g7XJDH/eMWOULlOp+U3bLb01wkgBgVLQTKK6ccPqZmJMy5bP96WgRvXrRkpkYRVIK5Yki+jb4VvrNIK/pKbnDfDPDZqh/0glY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; 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=b2kkepNrHD7xUJJR2Uy/aBe+rg3/en3P2qZGpNsmheTaAWJvxBEHHsCoyonh31dA4IYaPpIurRvK3ZqbkMfD9+RvIaxlpRuLoz/ykCE+jVGO8HABlV1LBvk7TSnS6/EmQ4OX2p3Z2IabwmPGiZHly03YyNbUPmuWjTMDhDfRySg= Received: by 10.141.79.12 with SMTP id g12mr3620975rvl.1193782790498; Tue, 30 Oct 2007 15:19:50 -0700 (PDT) Received: by 10.141.194.16 with HTTP; Tue, 30 Oct 2007 15:19:50 -0700 (PDT) Message-ID: <9bbcef730710301519p2931006aq5ba3a94fa1cc67c5@mail.gmail.com> Date: Tue, 30 Oct 2007 23:19:50 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <2979.1193779624@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9bbcef730710300648s4a4162a9x25e5a092111eaab9@mail.gmail.com> <2979.1193779624@critter.freebsd.dk> X-Google-Sender-Auth: a2ec1bac3f02b175 Cc: 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: Tue, 30 Oct 2007 22:26:30 -0000 On 30/10/2007, Poul-Henning Kamp wrote: > In message <9bbcef730710300648s4a4162a9x25e5a092111eaab9@mail.gmail.com>, "Ivan > Voras" writes: > >I think the context of my quote was in favour of this, as long as the > >language remains standard. > > But then again, what exactly is "standard" in this context ? > > C99 ? or style(9) ? > > We already use a C-diallect, all I'm proposing is giving it more > theeth so it can help us. Maybe I can better explain my thoughts and what I mean by "ugly" by giving an example. This: SLIST_FOREACH(a,b,c) { } is ugly (one of the reasons is that you need to pass the linkage field name all the time). This: for x in list { } is not. (Yes, the last one looks like a bastard offspring of C and Python, but it's a coincidence). Tree macros are worse, among other things for the fact that you constantly need to pass the type name as an argument. I'm not trying to insult the authors and users of these macros - they are both convenient and powerful, but you can only go so far with macros and preprocessor magic before the whole things starts to sprout mental spikes. I.e. I'd like something like that to be done right - if a different language is really needed, than accept a different language (not butcher C into obedience) as long as it's well defined and used by more than a dozen people on the Earth. Re: C++: This: for (vector::iterator it = v.begin(); it != v.end(); ++it) still looks pretty ugly but at least it's known to almost any CS/IT undergrad out there. My personal choice of a "C++ done right" language is D, it has this variant: foreach(i, a; args) writefln("args[%d] = '%s'", i, a); From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 23:42:55 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 DAEA016A41A for ; Tue, 30 Oct 2007 23:42:55 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by mx1.freebsd.org (Postfix) with ESMTP id 43A1B13C4B3 for ; Tue, 30 Oct 2007 23:42:55 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UNOG7n002457 for ; Wed, 31 Oct 2007 01:24:22 +0200 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 01:24:16 +0200 Received: from siebe101.NOE.Nokia.com ([172.30.195.47]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 07:24:13 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Oct 2007 07:24:15 +0800 Message-ID: In-Reply-To: <20071030120053.72A1916A480@hub.freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C++ in the kernel Thread-Index: Acga7JUvXddvsxIDRPqwfXuRP+NYcwAWAPMA References: <20071030120053.72A1916A480@hub.freebsd.org> From: To: X-OriginalArrivalTime: 30 Oct 2007 23:24:13.0938 (UTC) FILETIME=[FBB32D20:01C81B4B] X-Nokia-AV: Clean 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: Tue, 30 Oct 2007 23:42:55 -0000 I really try to avoid these type of discussions but it occurs to me that perhaps no-one on the list has much experience with actually using C++ in a kernel or even embedded environment. Since I have done ULTRIX, OSF1, NetBSD, Linux and now FreeBSD kernel work at various times plus embedded device work on Motorola Digital Set Top Boxes maybe I can add some first hand experience anecdotes. I will stay away from whether or not it is a good idea for your FreeBSD particular situation. So I worked for a voice recognition startup for about 7 years attempting to bring true voice control to the Digital Cable market, you know things like "Find movies with John Wayne". Anyway we started doing this on a M68K based STB with only 1.5 MB or flash and 1.5MB of RAM and no disks. The processor was clocked at 27Mhz but really ran at an equivalence of 7Mhz due to the fact that there was no cache whatsoever so it was usually waiting for data. Why is all this important to mention ? Mainly because the type of solution we were creating had to do a lot of data manipulation and some reasonably complex stuff on the STB before it sent anything to the headend. It would have taken us a lot longer than we had to create all the structures (hash tables, maps, communication protocols, device handlers) using C even though that was the only language supported on these primitive boxes. Instead we took one engineer aside and ported the gnu C++ toolchain. We also created a H/W Serial/USB BDM device that allowed stepping the OS code and used gdb on the other end to debug. What we got for that one engineers effort was a development environment not seen on those STBs ever and a productivity gain that allowed 4 engineers to develop a very complex product. The environment was then ported to the MIPs based STBs but stopped short of an equivalent JTAG based debugging dongle due to the company changing directions to Mobile phones at that point.=20 What we learnt from all this was close to what you have all been mentioning in one way or another. The Bad Things : * Exceptions are a hideous hack and compilers generated code is not efficient at dealing with them, outlaw them from the start or even remove them from the compiler somehow (i.e. a switch). * RTTI is a large consumer of space although you always find you semi re-invent the same mechanisms the minute you start to get serious about polymorphism to reduce code. * Multiple inheritance is just as big a mess as exceptions for OS applications, outlaw it since for starters it tends to lure you into needing RTTI but in general its just ugly. The Good Things : * STL is surprisingly damn useful. Being able to use AVL maps, lists, queues, iterators makes coding data structures intuitive and simple. The tricks we learnt were that STL only bloats if you use a lot of key/data types, restrict yourself to a well defined set of keys (i.e. only ints of various sizes) and a limited set of data (i.e. normally something akin To void *) and then static cast to what you need based on the fact that the class that puts stuff into a STL structure is the one that pulls it out and hands it off so it KNOWS what the type should be. * STL chunking of memory needs to be looked at, the problem is that most STL implementations assume that they are running in a process that on exit will have its memory cleaned up for it. Because of this it implements chunking of STL node memory in a very efficient way, but one that assumes it never gives back memory and a way that can cause memory fragmentation. Spending a few weeks fixing this allowed us to extensively use STL in an environment of 1.5MB where we were caching a lot of data.=20 * Polymorphism really helps in low level work, more than you would ever think. I would be certain that device drivers could make good use of it, I certainly did when doing software handlers for Digital Tunners on the STB. File systems as well seem like a natural fit given that you are already using an OO approach to them. * Name spacing is simply a god send. It stops people worrying about prefixs on functions. =20 * SmartObjects (i.e. those that are able to delete themselves when no-one is referencing them any longer) virtually eliminated any chance of memory leaks. This is akin to how JAVA does things but simply hugely more efficient. It costs just a single counter in each object if you are careful about the implementation. We literally never had to debug an invalid reference to an object or a memory leak in the C++ code. The same approach can be taken for SMP locks in a C++ environment which I have done at application level but not had the chance in the kernel yet. * All the reverse engineering tools like Umbrello, Borland Together, Rational Rose was available to help produce automated documentation and diagramatic views of the design. It's a sad fact that Structured Programming never received this sort of support from design tools. So I guess to summarise, the environement we were developing in was probably closest to the concept of Loadable Kernel modules in FreeBSD. We produced our own middleware and applications that got loaded off the Cable network onto the STBS. However it was very low level as well as having to do quite complex data manipulation on a very constrained device. We wouldn't have even gotten close to what we achieved without using C++ rather than the preferred vendor endorsed C approach at that time. In addition the OO paradigm made it easier to explain very complex interactions between system components.=20 I suspect eventually there will be no choice as the OS gets more and more complex that someone will bring in a true OO language into the kernel. For my money the obvious starting place would be to support it in loadable kernel modules. Cheers and I hope I haven't ranted too much. John Court From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 23:56:22 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 23E2316A418 for ; Tue, 30 Oct 2007 23:56:22 +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 1616A13C4A3 for ; Tue, 30 Oct 2007 23:56:21 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 6F3D11A4D81; Tue, 30 Oct 2007 16:00:13 -0700 (PDT) Date: Tue, 30 Oct 2007 16:00:13 -0700 From: Alfred Perlstein To: Maciej Sobczak Message-ID: <20071030230013.GB33488@elvis.mu.org> References: <23408.1193557610@critter.freebsd.dk> <20071030055840.GS33488@elvis.mu.org> <47274A29.9040801@msobczak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47274A29.9040801@msobczak.com> User-Agent: Mutt/1.4.2.3i Cc: 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: Tue, 30 Oct 2007 23:56:22 -0000 * Maciej Sobczak [071030 15:55] wrote: > Alfred Perlstein wrote: > > >I think the right thing to do here is to identify the things we > >need added to C++ and propose those to the standards. > > I think you got it completely backwards. > > First a bit of context - the C++ standard committee is already in deep > sht^H^H^Hwork to get the current proposals straight and ship the new > standard revision, which is already late. No new proposals are accepted, > unless they save the world. > Considering the usual rythm of standardization process, the next chance > to add anything to C++ will be at the end of the next decade. FreeBSD > might be already dead till that time with Linux overtaking whatever is > left from the community. > > You should reverse your thinking and instead ask yourself: what parts > and elements of *current* C++ might be useful for kernel development? > If you identify them you can actually benefit from adapting them. > If not, abandon the idea altogether and continue the current way. > If you try to do anything else, you will only waste resources. I agree that we can use what's currently in C++, additional things we can hack in ourselves and/or propose in the meanwhile. > Actually, C++ is being used in embedded and real-time systems as well as > for signal processing, so apparently there *are* some communities that > already gained experience with constrained use of the language. > Presumably some of the constraints that these people face are also valid > in the kernel world, and presumably some of the solutions might be > successfully reused. > Don't reinvent! Yes. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 00:55:37 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 88DAC16A46D for ; Wed, 31 Oct 2007 00:55:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACDE13C4A3 for ; Wed, 31 Oct 2007 00:55:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2785974waf for ; Tue, 30 Oct 2007 17:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LeRY3uoZTFHLklnvjZWzaifnyxTTr7353Bymx0KqnZM=; b=P6/KK3nB9bwjlba8pLJPNWkV7aq0mBBl3Ccv2mTNgCNFO9KNyhm+BPEY5LwpUWKjpM23QY5WFi3Hyt1zsIM85s9TA83dpMUOmnvhRwDRZPBJUd+SOXcDsJh/pAiKAEvGIhmm/WNX6960IxE/V3OhgKgiANJQwfyVZDWWcdy1IaA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LOacFHiL9v6lQnDTJFxU3KEtRSs/7e1Z3MM0FeqdPPqglBYmMkEwxx/2UhPKjvTNVuQupcucmjjZhKMrmrlBM8rAsz/gmMYXrmO0l5y/LeqRwQLL8NGb73l3MrsAODZldbqNakRg1hru5+PXVunhgkJMQupnSFh0atm3RaISfJ4= Received: by 10.114.137.2 with SMTP id k2mr5428926wad.1193792127627; Tue, 30 Oct 2007 17:55:27 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Tue, 30 Oct 2007 17:55:27 -0700 (PDT) Message-ID: Date: Tue, 30 Oct 2007 17:55:27 -0700 From: "Kip Macy" To: "Poul-Henning Kamp" In-Reply-To: <1821.1193764478@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071030163613.E70665B30@mail.bitblocks.com> <1821.1193764478@critter.freebsd.dk> Cc: 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: Wed, 31 Oct 2007 00:55:37 -0000 > Pointer colors > -------------- > > void * "userland" ptr; > > Cannot be used as regular void *, but must be passed to > functions which has same color prototype. > > Integer endianess > ----------------- > > uint32_t big_endian foo; > > Atomic variables > ---------------- > > uint32_t atomic foo; I know just from working in the linux code that sparse already supports at least these 3 checks. I'm not saying this to advocate the use of sparse but to point out that the use of annotations are already being used to good effect on kernel code and are in not in anyway "exotic". I like the notion of K, but share the concerns that most everyone has, and phk recognizes, about long-term maintenance of "Kfront". -Kip -Kip From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 01:16:55 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 F2B3E16A417 for ; Wed, 31 Oct 2007 01:16:55 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id B8A7813C465 for ; Wed, 31 Oct 2007 01:16:55 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l9V1GLYK003534 for ; Tue, 30 Oct 2007 21:16:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <47274A29.9040801@msobczak.com> References: <23408.1193557610@critter.freebsd.dk> <20071030055840.GS33488@elvis.mu.org> <47274A29.9040801@msobczak.com> Date: Tue, 30 Oct 2007 21:16:20 -0400 To: freebsd-arch@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Cc: 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: Wed, 31 Oct 2007 01:16:56 -0000 At 4:13 PM +0100 10/30/07, Maciej Sobczak wrote: >Alfred Perlstein wrote: > >(I reply also to some previous mail which I didn't get from the list.) Which came from me... I probably should have sent it to the list, but at the time it seemed something was haywire with my mail. An earlier message I had sent to the list didn't show up for quite a long time. >>>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. > >Do you often change the compiler in the middle of a STABLE branch? >If not, then why are you worried about changes in the language? >They will not magically propagate to the compiler. > >Pick the compiler version and stick to it for the whole branch lifetime. Yes. Just Like Perl. What harm harm can possibly come to sticking with Perl4 in a stable branch? And certainly we've seen major incompatible changes to C++ at the *ABI-level* in the past. >>>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++. > >Why are you worried about developments that can come up? >Do you try to protect yourself from new developments that >can come up in C as well? You don't own neither C++, nor C. Yes, I know we don't own C++. That was my whole point. It seems to me that PHK wants to stick with be very careful with what we introduce to kernel-level programming, and that seems quite reasonable and prudent, IMO. I *like* playing with a wide variety of languages when it comes to user-level applications, but I can see that we need tighter control when it comes to the kernel. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 01:23:28 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 3122316A421 for ; Wed, 31 Oct 2007 01:23:28 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id B6FE013C4A5 for ; Wed, 31 Oct 2007 01:23:27 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l9V1N3MV005635; Tue, 30 Oct 2007 21:23:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <47274A29.9040801@msobczak.com> References: <23408.1193557610@critter.freebsd.dk> <20071030055840.GS33488@elvis.mu.org> <47274A29.9040801@msobczak.com> Date: Tue, 30 Oct 2007 21:23:02 -0400 To: Maciej Sobczak , freebsd-arch@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Cc: 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: Wed, 31 Oct 2007 01:23:28 -0000 At 4:13 PM +0100 10/30/07, Maciej Sobczak wrote: > >(I reply also to some previous mail which I didn't get from the list.) Hmm, actually you were replying to the message which I *did* send to the mailing list. I don't know why you didn't see it. Maybe something did go wrong with the mailing list at around the time that I sent it. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 01:27:35 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 CC53516A420; Wed, 31 Oct 2007 01:27:35 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id CEEA013C48A; Wed, 31 Oct 2007 01:27:34 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup55.ach.sch.gr [81.186.70.55]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l9V1CDiQ012508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2007 03:12:49 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l9V1C3fd033586; Wed, 31 Oct 2007 03:12:03 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l9V1Bbw8033585; Wed, 31 Oct 2007 03:11:37 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 31 Oct 2007 03:11:36 +0200 From: Giorgos Keramidas To: Bakul Shah Message-ID: <20071031011136.GA33331@kobe.laptop> References: <20071030055840.GS33488@elvis.mu.org> <20071030163613.E70665B30@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071030163613.E70665B30@mail.bitblocks.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.925, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.47, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Poul-Henning Kamp , Alfred Perlstein , Garance A Drosehn , 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: Wed, 31 Oct 2007 01:27:35 -0000 On 2007-10-30 09:36, Bakul Shah wrote: > The structured macro paper referenced on the K wiki page also > seems rather interesting. A powerful macro facility needs to > be well integrated with the language (much like Lisp or > Scheme's macros) so that you can write for instance > > critical_section(lock) { > ... > bar: > ... > if (cond1) break; > ... > if (cond2) goto foo; > ... > if (cond3) goto bar; > ... > if (cond4) return; // from enclosing function > ... > } > ... > foo: > > and have it transform to vanilla C code that does proper > unlocking on any exit. To a first approximation I think of > them as compile time "functions" that take identifiers and code > as arguments and return code. That sounds interesting indeed. Even userlevel code can benefit greatly from a structured macro enhancement to plain, vanilla C. I've been reading a lot about macros in both C and Lisp Usenet groups, but I am not sure how feasible it would be to have in a C-like language the deeply integrated macros like: (exception-handling-code (critical-section (lock) ...)) without an equivalently advanced mechanism for handling exceptions in the case the macros fail. At least, not in a way that doesn't make the C-like language sufficiently unportable to be tricky to implement & use. For example, in the critical_section() macro above, 'break' is a quite 'plain' C feature, but it should suddenly grow enough knowledge about the encapsulating macro to DTRT. The 'return' keyword is similar. Anything that is related to scope of the lock object too, and we are already in our way to design something that is superficialy similar to C but only in a very basic level of syntax :/ > Coming up with something that is semantically well defined & > integrates well with C can not be easy. All budding feature > designers ought to read Tony Hoare's "Hints on programming > language design". Still relevant after 33 years. Search for > cb-p193-hoare.pdf. Right on the spot, indeed. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 11:07:41 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 176F416A420; Wed, 31 Oct 2007 11:07:41 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id DAB5313C48D; Wed, 31 Oct 2007 11:07:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l9VB6XoN003596; Wed, 31 Oct 2007 04:06:33 -0700 (PDT) Date: Wed, 31 Oct 2007 20:06:33 +0900 Message-ID: From: "George V. Neville-Neil" To: Giorgos Keramidas In-Reply-To: <20071031011136.GA33331@kobe.laptop> References: <20071030055840.GS33488@elvis.mu.org> <20071030163613.E70665B30@mail.bitblocks.com> <20071031011136.GA33331@kobe.laptop> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Poul-Henning Kamp , Alfred Perlstein , Garance A Drosehn , 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: Wed, 31 Oct 2007 11:07:41 -0000 Not to jump in here and ruin the thread, but unless I missed something, the thing that's missing here is the grounding, that is, "What do we need C++, or for that matter, a kernel language for?" When Poul-Henning and I talked about K, and when I saw what a hash has often been made of kernel like systems (RTOSs as well as bigger OS Kernels) the list that popped into my mind had bits of this conversation: 1) Better support for locking primitives That is, locking primitives that can be better instrumented etc. 2) Support for components. Right now this can be done with klds but something like them as a first class feature of a language would be useful to us. 3) Something like the STL. It would be nice if we didn't re-invent the (as Kip put it) CS101 primitives. The problems with C++ are both political and technical. The political are likely the more formidable ones, but let's face it we're doing C++ like things in the kernel now (structures of pointers ARE vtables, and vice versa). It might be that a small extension to C is the right way to move towards a more powerful set of tools for kernel developement without scaring people with the C++ bogeyman (bogeyperson? ;-) What is needed to move all this forwards is either one of the following: 1) A serious proposal on C++ in the kernel that includes: a) The restricted subset of C++ we would be willing to entertain. b) A demonstration of the kernel built and running from a C++ compiler. 2) A serious proposal on a C extension language that includes: a) The list of primitives that are being added, their purposes, and how they are better than what we have now. b) A demonstration of the kernel built and running from such a set of extensions. The biggest problem here is that we'd need people committed to doing this who can work with the community. I believe this is why the K efforts, which I have been a part of and take some responsibility for, have failed. You need a group of people with experience and drive to make this work, not a bunch of us hand waving in email. Best, George From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 15:58:09 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 61E6E16A421; Wed, 31 Oct 2007 15:58:09 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 367E313C49D; Wed, 31 Oct 2007 15:58:09 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 4395A5B59; Wed, 31 Oct 2007 08:32:48 -0700 (PDT) To: Alfred Perlstein In-reply-to: Your message of "Tue, 30 Oct 2007 13:12:29 PDT." <20071030201229.GA33488@elvis.mu.org> Date: Wed, 31 Oct 2007 08:32:48 -0700 From: Bakul Shah Message-Id: <20071031153248.4395A5B59@mail.bitblocks.com> Cc: Poul-Henning Kamp , Garance A Drosehn , 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: Wed, 31 Oct 2007 15:58:09 -0000 > > > > critical_section(lock) { > > > > ... > > > > bar: > > > > ... > > > > if (cond1) break; > > > > ... > > > > if (cond2) goto foo; > > > > ... > > > > if (cond3) goto bar; > > > > ... > > > > if (cond4) return; // from enclosing function > > > > ... > > > > } > > > > ... > > > > foo: > > > > > > > > > do you mean like C++: > > > > > > do { > > > critical_object critical_instance(); > > > > > > > > > > > > > > > } > > > > No idea but I can not see how that will do what I had in mind. A purely > > lexical translation of the snippet I gave above would be something like: > > You can create an object on the stack that locks the mutex given > to it like so: > > do { > mtx_lock_object mtx_locker(&lock); > > } > > When the object is destroyed by stack popping, the lock will be freed. > > It's the same thing. Yes indeed, thanks! I am starting to forget all the C++ tricks I learned. Mercifully. Two points though. This was an example of what is possible with macros that can inspect their argument code + they can also do many other things that don't fit so easily with C++'s initialization/finalization trick. For example what if you can't gain the lock and want to do something else? Two, while C++ gives you a way to solve this problem, it does it in a "clever" way, not an obvious way. But I will acknowledge I am comparing vaporware with something that works now! From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 17:59:57 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 E507316A417; Wed, 31 Oct 2007 17:59:57 +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 D0A1613C4AA; Wed, 31 Oct 2007 17:59:57 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5139C1A4D8D; Wed, 31 Oct 2007 10:04:39 -0700 (PDT) Date: Wed, 31 Oct 2007 10:04:39 -0700 From: Alfred Perlstein To: Jan Grant Message-ID: <20071031170439.GE35925@elvis.mu.org> References: <20071031153248.4395A5B59@mail.bitblocks.com> <20071031161042.T41569@tribble.ilrt.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071031161042.T41569@tribble.ilrt.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: Poul-Henning Kamp , Garance A Drosehn , 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: Wed, 31 Oct 2007 17:59:58 -0000 * Jan Grant [071031 09:57] wrote: > On Wed, 31 Oct 2007, Bakul Shah wrote: > > > For example what if you can't gain the lock and want > > to do something else? Two, while C++ gives you a way to > > solve this problem, it does it in a "clever" way, not an > > obvious way. > > RAII is a very common C++ idiom; that kind of thing'd be obvious to > anyone who's mired^Wimmersed in C++ on a regular basis. > > That's the point here - if this was the language technology already in > use, then it'd be obvious, and nobody would think much about it. It's > not, so it looks alien, much like any other alternatives that'll get > raised along the line of C-plus-stuff look alien. Amongst C++ users with > taste (and I claim that they do exist) the natural question that'll then > be asked is, since you can already express this idea in C++ why would > you adopt a less widespread (or novel) language? > > jan > > PS. Paint it green. Hhehehehe.... { mutex_locker_trylock trylock(&mutex); if (trylock.success()) { } else { } } // regardless if it succeeded, lock is now dropped. I think this might even work: { if (mutex_locker_trylock trylock(&mutex).success()) { } else { } } brb, gonna throw up. :) -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 19:05:31 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 18A0C16A41A for ; Wed, 31 Oct 2007 19:05:31 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C60E113C4A6 for ; Wed, 31 Oct 2007 19:05:30 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1InHT4-00081s-2T for freebsd-arch@freebsd.org; Wed, 31 Oct 2007 17:35:02 +0000 Received: from xdsl-10260.wroclaw.dialog.net.pl ([84.40.242.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 17:35:02 +0000 Received: from mwisnicki+freebsd by xdsl-10260.wroclaw.dialog.net.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 17:35:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Marcin Wisnicki Date: Wed, 31 Oct 2007 17:19:19 +0000 (UTC) Lines: 21 Message-ID: References: <9bbcef730710300648s4a4162a9x25e5a092111eaab9@mail.gmail.com> <2979.1193779624@critter.freebsd.dk> <9bbcef730710301519p2931006aq5ba3a94fa1cc67c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: xdsl-10260.wroclaw.dialog.net.pl User-Agent: Pan/0.131 (Ghosts: First Variation) Sender: news 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: Wed, 31 Oct 2007 19:05:31 -0000 On Tue, 30 Oct 2007 23:19:50 +0100, Ivan Voras wrote: > Re: C++: This: > > for (vector::iterator it = v.begin(); it != v.end(); ++it) > > still looks pretty ugly but at least it's known to almost any CS/IT > undergrad out there. > > My personal choice of a "C++ done right" language is D, it has this > variant: > > foreach(i, a; args) > writefln("args[%d] = '%s'", i, a); You can do something like this in c++, for example with boost::foreach: #include #define foreach BOOST_FOREACH foreach(int i, v) { } From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 20:01:02 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 387EC16A419; Wed, 31 Oct 2007 20:01:02 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id EBF6913C4A8; Wed, 31 Oct 2007 20:01:01 +0000 (UTC) (envelope-from jan.grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1InGGs-0007Hf-BX; Wed, 31 Oct 2007 16:18:23 +0000 Received: from cse-jg.cse.bris.ac.uk ([137.222.12.37]:51810) by mail.ilrt.bris.ac.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1InGGg-0002aW-Fg; Wed, 31 Oct 2007 16:18:10 +0000 Date: Wed, 31 Oct 2007 16:18:10 +0000 (GMT) From: Jan Grant X-X-Sender: cmjg@tribble.ilrt.bris.ac.uk To: Bakul Shah In-Reply-To: <20071031153248.4395A5B59@mail.bitblocks.com> Message-ID: <20071031161042.T41569@tribble.ilrt.bris.ac.uk> References: <20071031153248.4395A5B59@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ILRT-MailScanner: Found to be clean X-ILRT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.682, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 1.72, BAYES_00 -2.60) X-ILRT-MailScanner-From: jan.grant@bristol.ac.uk X-Spam-Status: No X-Spam-Score: -0.8 X-Spam-Level: / Cc: Poul-Henning Kamp , Alfred Perlstein , Garance A Drosehn , 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: Wed, 31 Oct 2007 20:01:02 -0000 On Wed, 31 Oct 2007, Bakul Shah wrote: > For example what if you can't gain the lock and want > to do something else? Two, while C++ gives you a way to > solve this problem, it does it in a "clever" way, not an > obvious way. RAII is a very common C++ idiom; that kind of thing'd be obvious to anyone who's mired^Wimmersed in C++ on a regular basis. That's the point here - if this was the language technology already in use, then it'd be obvious, and nobody would think much about it. It's not, so it looks alien, much like any other alternatives that'll get raised along the line of C-plus-stuff look alien. Amongst C++ users with taste (and I claim that they do exist) the natural question that'll then be asked is, since you can already express this idea in C++ why would you adopt a less widespread (or novel) language? jan PS. Paint it green. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ There's no convincing English-language argument that this sentence is true. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 20:46:41 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 09AB216A419; Wed, 31 Oct 2007 20:46:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8C82313C481; Wed, 31 Oct 2007 20:46:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id l9VKZ4vL093013; Wed, 31 Oct 2007 14:35:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 31 Oct 2007 14:36:52 -0600 (MDT) Message-Id: <20071031.143652.84363262.imp@bsdimp.com> To: alfred@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20071030230013.GB33488@elvis.mu.org> References: <20071030055840.GS33488@elvis.mu.org> <47274A29.9040801@msobczak.com> <20071030230013.GB33488@elvis.mu.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: prog@msobczak.com, 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: Wed, 31 Oct 2007 20:46:41 -0000 In message: <20071030230013.GB33488@elvis.mu.org> Alfred Perlstein writes: : I agree that we can use what's currently in C++, additional things : we can hack in ourselves and/or propose in the meanwhile. Most of the C++ features are implemented in libraries, even low level things like exceptions and rtti. One can often disable a feature by refusing to provide the support routines. No support routine, kernel can't link, no problems created by naive use :-) Warner From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 21:02:52 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 8F86416A417 for ; Wed, 31 Oct 2007 21:02:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id F288E13C4A5 for ; Wed, 31 Oct 2007 21:02:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com ([62.64.120.197]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1InF9Z-0007BU-R1 for freebsd-arch@freebsd.org; Wed, 31 Oct 2007 17:06:45 +0200 Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1InF9S-0009J9-Tc for freebsd-arch@freebsd.org; Wed, 31 Oct 2007 17:06:45 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l9VF6NDi000409 for ; Wed, 31 Oct 2007 17:06:23 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l9VF6KgE000408 for freebsd-arch@freebsd.org; Wed, 31 Oct 2007 17:06:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 31 Oct 2007 17:06:20 +0200 From: Kostik Belousov To: freebsd-arch@freebsd.org Message-ID: <20071031150620.GT37471@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dLXnlYbDJNCwF3YM" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 4fe2b897d4d72954524b6b73d18f8617 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1716 [Oct 31 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Subject: fdclone KPI 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: Wed, 31 Oct 2007 21:02:52 -0000 --dLXnlYbDJNCwF3YM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear arch@ readers, with the important help from Peter Holm I have implemented the KPI that provides the ability for the driver to implement cloning on the open(2). This is another (IMHO, more UNIXy) way to provide per-fd private data for the driver. It seems that at least /dev/apm, /dev/drm and /dev/sg could immediately benefit from the fdclone() KPI. The patch is at http://people.freebsd.org/~kib/misc/fdclone.9.patch Sample dumb driver that uses the KPI is at http://people.freebsd.org/~kib/fclone The driver that uses the fdclone() shall provide cdevsw for master device, and cdevsw for clones. Master shall have d_fdopen() method that could call int fdclone(struct cdevsw *_csw, struct file *_fp, int _fmode, struct cdev **_clone, void *si_drv1, struct thread *td); to replace the reference in the _fp with newly created cdev. After successfull fdclone() call, all further calls on the _fp are dispatched to the clone _csw instead of master one. si_drv1 of the new cdev is set to respective argument, allowing the clone to find the master. The cloned cdev is not accessible for lookup through the devfs, and is destroyed automatically on the final close of the last filedescriptor that references the vnode. Please, review. Your feedback is welcome ! --dLXnlYbDJNCwF3YM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHKJnrC3+MBN1Mb4gRAt8PAJ0W4QLnP644wDgrWJ4XLqYg9iPyxgCdFbo3 EtzhD11yGt+MgtJWLOzQarE= =nACF -----END PGP SIGNATURE----- --dLXnlYbDJNCwF3YM-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 1 08:05:28 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 B8C3B16A41B for ; Thu, 1 Nov 2007 08:05:28 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7205B13C4AC for ; Thu, 1 Nov 2007 08:05:28 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1InIr8-0007aK-N6 for freebsd-arch@freebsd.org; Wed, 31 Oct 2007 19:03:58 +0000 Received: from xdsl-10260.wroclaw.dialog.net.pl ([84.40.242.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 19:03:58 +0000 Received: from mwisnicki+freebsd by xdsl-10260.wroclaw.dialog.net.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Oct 2007 19:03:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Marcin Wisnicki Date: Wed, 31 Oct 2007 19:03:48 +0000 (UTC) Lines: 21 Message-ID: References: <9bbcef730710300648s4a4162a9x25e5a092111eaab9@mail.gmail.com> <2979.1193779624@critter.freebsd.dk> <9bbcef730710301519p2931006aq5ba3a94fa1cc67c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: xdsl-10260.wroclaw.dialog.net.pl User-Agent: Pan/0.131 (Ghosts: First Variation) Sender: news 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: Thu, 01 Nov 2007 08:05:28 -0000 On Tue, 30 Oct 2007 23:19:50 +0100, Ivan Voras wrote: > Re: C++: This: > > for (vector::iterator it = v.begin(); it != v.end(); ++it) > > still looks pretty ugly but at least it's known to almost any CS/IT > undergrad out there. > > My personal choice of a "C++ done right" language is D, it has this > variant: > > foreach(i, a; args) > writefln("args[%d] = '%s'", i, a); You can do something like that in c++, for example with boost::foreach: #include #define foreach BOOST_FOREACH foreach(int i, v) { } From owner-freebsd-arch@FreeBSD.ORG Fri Nov 2 19:43:28 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 275DF16A41A; Fri, 2 Nov 2007 19:43:28 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id E061B13C49D; Fri, 2 Nov 2007 19:43:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E4A10451A6; Fri, 2 Nov 2007 12:39:15 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 02 Nov 2007 12:39:15 -0400 X-Sasl-enc: Xygx/WwiT/YJyJhDllFrKq0ysbQIRfOkybDuEeeaB7eT 1194021555 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4AC46274E6; Fri, 2 Nov 2007 12:39:15 -0400 (EDT) Message-ID: <472B52B2.9040901@incunabulum.net> Date: Fri, 02 Nov 2007 16:39:14 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Poul-Henning Kamp References: <13151.1193483977@critter.freebsd.dk> In-Reply-To: <13151.1193483977@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , 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 19:43:28 -0000 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 From owner-freebsd-arch@FreeBSD.ORG Fri Nov 2 20:53:16 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 9829216A41A; Fri, 2 Nov 2007 20:53:16 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A3A1713C48A; Fri, 2 Nov 2007 20:53:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3C65717105; Fri, 2 Nov 2007 20:52:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id lA2Kqp4p004756; Fri, 2 Nov 2007 20:52:52 GMT (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Nov 2007 13:38:03 MST." <20071102203803.GO77844@elvis.mu.org> Date: Fri, 02 Nov 2007 20:52:51 +0000 Message-ID: <4755.1194036771@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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 20:53:16 -0000 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 2 21:06:48 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 9071916A41B for ; Fri, 2 Nov 2007 21:06:48 +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 7B5A113C4AA for ; Fri, 2 Nov 2007 21:06:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id DA1B01A4D81; Fri, 2 Nov 2007 13:38:03 -0700 (PDT) Date: Fri, 2 Nov 2007 13:38:03 -0700 From: Alfred Perlstein To: Bruce M Simpson Message-ID: <20071102203803.GO77844@elvis.mu.org> References: <13151.1193483977@critter.freebsd.dk> <472B52B2.9040901@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472B52B2.9040901@incunabulum.net> User-Agent: Mutt/1.4.2.3i Cc: Poul-Henning Kamp , 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:06:48 -0000 * Bruce M Simpson [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 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 From owner-freebsd-arch@FreeBSD.ORG Sat Nov 3 10:50:45 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 B5DCD16A419; Sat, 3 Nov 2007 10:50:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx02.syd.optusnet.com.au (fallbackmx02.syd.optusnet.com.au [211.29.133.72]) by mx1.freebsd.org (Postfix) with ESMTP id 32E0113C4BB; Sat, 3 Nov 2007 10:50:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx02.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l9VGn8Di030089; Thu, 1 Nov 2007 03:49:08 +1100 Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l9VGlrv4006843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2007 03:48:07 +1100 Date: Thu, 1 Nov 2007 03:48:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "David O'Brien" In-Reply-To: <20071026163923.GA95109@dragon.NUXI.org> Message-ID: <20071101032901.L4676@delplex.bde.org> References: <20071026163923.GA95109@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Filesystem INVARIANTS 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: Sat, 03 Nov 2007 10:50:45 -0000 On Fri, 26 Oct 2007, David O'Brien wrote: > Hi folks, > > Looking at the code in sys/ufs, I think most of the "DIAGNOSTIC"s should > really be "INVARIANTS"s. In fact there are no "INVARIANTS" in the > filesystem code at this time. I like not having much clutter from INVARIANTS/KASSERT()s, but having things under DIAGNOSTICs isn't right. In fs code, there should be some unconditional checking that the file system isn't corrupt. That doesn't belong under any ifdefs (since the errors it finds are more like errors in user input than logic errors), and it mostly already isn't. > Below is a diff of what I feel should change from "DIAGNOSTIC" to > "INVARIANTS". I have not yet had a chance to benchmark the impact of > this change when only INVARIANTS/INVARIANTS_SUPORT and not DIAGNOSTIC is > set vs. nothing set. This changes a few things that are probably only caused by corrupt file systems, and many things where it isn't clear what the causes might be. OTOH, there are lots of panics that aren't under any ifdef but are probably only caused by logic errors. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Nov 3 19:52:09 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 B39A816A418 for ; Sat, 3 Nov 2007 19:52:09 +0000 (UTC) (envelope-from streamsendbouncer@me34859.mailengine3.com) Received: from me34859.mailengine3.com (me34859.mailengine3.com [72.19.233.24]) by mx1.freebsd.org (Postfix) with ESMTP id D54C313C4C3 for ; Sat, 3 Nov 2007 19:52:04 +0000 (UTC) (envelope-from streamsendbouncer@me34859.mailengine3.com) Received: by me34859.mailengine3.com (PowerMTA(TM) v3.2r16) id h5j8me0eutcm for ; Sat, 3 Nov 2007 12:50:44 -0700 (envelope-from ) MIME-Version: 1.0 X-Mailer: StreamSend - 34302 X-Report-Abuse-At: abuse@streamsend.com X-Report-Abuse-Info: It is important to please include full email headers in the report X-Campaign-ID: 192 X-Streamsendid: 34302+72+347121+192+me34859.mailengine3.com Date: Sat, 03 Nov 2007 12:50:40 -0700 From: "Tack Wholesale" To: freebsd-arch@freebsd.org Message-Id: <20071103195204.D54C313C4C3@mx1.freebsd.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Request a Free Catalog and receive $10 off your first purchase 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: Sat, 03 Nov 2007 19:52:09 -0000 Request a free catalog and receive $10 your first purchase http://www.tackwholesale.com/Catalog_Request_Special02.htm put this link in your browser Click here on http://server1.streamsend.com/streamsend/unsubscribe.php?cd=34302&md=192&ud=0fa55a21584f2ce925f2533f7d3de2c8 to update your profile or Unsubscribe