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--