From alan From: Alan Cox Newsgroups: rhat.general.linux-kernel Subject: Re: Compiling C++ modules Date: Mon, 24 Apr 2006 21:45:46 +0100 Organization: Red Hat Inc. Internal News Lines: 55 Message-ID: References: In-Reply-To: X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Precedence: bulk X-Original-Cc: linux-kernel@vger.kernel.org X-Original-To: poppitzg@iomega.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Llu, 2006-04-24 at 13:16 -0600, Gary Poppitz wrote: > I have the task of porting an existing file system to Linux. This > code is in C++ and I have noticed that the Linux kernel has > made use of C++ keywords and other things that make it incompatible. We tried various things involving C++ along the line in kernel history and there are so many problems it throws up the kernel took the view that it would not use C++ in kernel. Instead object orientation is performed more explicitly in C. This has many advantages including the exposure of inefficient code explicitly and the avoidance of exceptions and the assumption memory allocations just don't fail that much C++ makes without exceptions being used. It might be possible to move to a strict C++ subset in the style of Apple but there isn't much interest in this. There are other problems too, notably the binary ABI between the C and C ++ compiler might not match for all cases (in particular there are corner cases with zero sized objects and C++). > I would be most willing to point out the areas that need adjustment > and supply patch files to be reviewed. > > What would be the best procedure to accomplish this? If you want to maintain your own out of tree file system then probably you want to use #defines to wrap the kernel tree. Most stuff will probably work ok if you do this although you'll want some C to C++ wrappers to interface to the kernel obviously. If you want to submit the file system to the kernel source then it needs shifting from C++ to C but of course there are people in the community who can help you. As the kernel C is very object based that isn't usually too much of a problem. Most objects in the kernel (inodes, files etc) are of the form struct thing { struct thing_ops *ops; /* methods */ blah } and that style fits much C++ code being ported over. There are a few anti C++ bigots around too, but the kernel choice of C was based both on rational choices and experimentation early on with the C++ compiler. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From torvalds From: Linus Torvalds Newsgroups: rhat.general.linux-kernel Subject: Re: C++ pushback Date: Wed, 26 Apr 2006 13:09:38 -0700 (PDT) Lines: 43 Message-ID: References: <20060426034252.69467.qmail@web81908.mail.mud.yahoo.com> <20060426200134.GS25520@lug-owl.de> In-Reply-To: <20060426200134.GS25520@lug-owl.de> X-Original-Cc: linux-kernel@vger.kernel.org X-Original-Cc: davids@webmaster.com X-Original-To: jbglaw@lug-owl.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Apr 2006, Jan-Benedict Glaw wrote: > > There's one _practical_ thing you need to keep in mind: you'll either > need 'C++'-clean kernel headers (to interface low-level kernel > functions) or a separate set of headers. I suspect it would be easier to just do extern "C" { #include ... } instead of having anything really C++'aware in the headers. If by "clean" you meant that the above works, then yeah, there might be _some_ cases where we use C++ keywords etc in the headers, but they should be pretty unusual and easy to fix. The real problem with C++ for kernel modules is: - the language just sucks. Sorry, but it does. - some of the C features we use may or may not be usable from C++ (statement expressions?) - the compilers are slower, and less reliable. This is _less_ of an issue these days than it used to be (at least the reliability part), but it's still true. - a lot of the C++ features just won't be supported sanely (ie the kernel infrastructure just doesn't do exceptions for C++, nor will it run any static constructors etc). Anyway, it should all be doable. Not necessarily even very hard. But I doubt it's worth it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From viro From: Al Viro Newsgroups: rhat.general.linux-kernel Subject: Re: C++ pushback Date: Wed, 26 Apr 2006 21:19:09 +0100 Lines: 21 Message-ID: References: <20060426034252.69467.qmail@web81908.mail.mud.yahoo.com> <20060426200134.GS25520@lug-owl.de> In-Reply-To: User-Agent: Mutt/1.4.1i X-Original-Cc: jbglaw@lug-owl.de X-Original-Cc: linux-kernel@vger.kernel.org X-Original-Cc: davids@webmaster.com X-Original-To: torvalds@osdl.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 26, 2006 at 01:09:38PM -0700, Linus Torvalds wrote: > The real problem with C++ for kernel modules is: > > - the language just sucks. Sorry, but it does. > - some of the C features we use may or may not be usable from C++ > (statement expressions?) > - the compilers are slower, and less reliable. This is _less_ of an issue > these days than it used to be (at least the reliability part), but it's > still true. > - a lot of the C++ features just won't be supported sanely (ie the kernel > infrastructure just doesn't do exceptions for C++, nor will it run any > static constructors etc). - a lot of C++ advocates agree that some subset could be used sanely, but there's no agreement as to _which_ subset would that be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/