Date: Tue, 30 Oct 2007 17:57:59 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel Message-ID: <20071030065759.GW70883@server.vk2pj.dyndns.org> In-Reply-To: <33676.1193689342@critter.freebsd.dk> References: <fg4bij$m42$1@ger.gmane.org> <33676.1193689342@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071030065759.GW70883>