Date: Wed, 31 Oct 2007 20:06:33 +0900 From: "George V. Neville-Neil" <gnn@neville-neil.com> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Alfred Perlstein <alfred@freebsd.org>, Garance A Drosehn <gad@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: C++ in the kernel Message-ID: <m2y7djmtl2.wl%gnn@neville-neil.com> In-Reply-To: <20071031011136.GA33331@kobe.laptop> References: <20071030055840.GS33488@elvis.mu.org> <20071030163613.E70665B30@mail.bitblocks.com> <20071031011136.GA33331@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2y7djmtl2.wl%gnn>