Messages in this thread |  | | Date | Sun, 15 Oct 2000 16:34:09 +0300 | From | Eray Ozkural <> | Subject | [Criticism] On the discussion about C++ modules |
| |
Hi,
I've read a summary of a discussion about C++ module writing on this list, and I'd like to make some comments on it. [I'm not subscribed to this list, please retain a Cc: to my address]
To rephrase, Stepan Kasal had started writing a C++ kernel module and while including kernel headers he found out that C++ reserved words were being used in some header files, thus resulting in errors. He proposed a patch to remedy this situation but as I see it was rejected on the grounds that C++ is not appropriate for kernel development.
First off, I'd like to state that kernel being a mostly C program may not have had such considerations. The responses however surprised me greatly, although I'm aware of Linus Torvald's general skepticism of the utility of C++ for kernel development. [I don't imply that all kernel hackers are his disciples]
If the conflict can be avoided outside linux source tree, it should be preferred. I have nothing to say about that. The quoted posts in the summary I've read will be subject to my humble criticism as I believe they were made without putting much thought to the subject matter but largely motivated by some need to advocate.
* Jes Sorensen has claimed that kernel modules should not be written in C++ on the grounds that " Once somebody has done it, somebody else will try to use some of the brain dread C++ features such as exceptions - therefore totally preventing people from writing any bits of the kernel in C++ is a good thing."
Exceptions are not a brain dead C++ feature, although I'd agree that C++ has many flaws. On the contrary [to what you say], exception handling in C++ standard has seemed to me one of the most efficient and simplistic ways to handle exceptions. Like in many languages, inappropriate ways of using a feature can result in awful side effects and overall undesirable system behavior. When writing systems software, one cannot attain the same style as though he's writing a word processor. I believe many people in this list can point out to badly written C code in some version of the linux tree.
OTOH, anybody can do anything they desire with the linux source code. And anybody can write any Linux kernel module they see fit. (I like 68k assembly a lot, can't I write a module with it?)
[A note on C++ exceptions: they were designed to cause no overhead when they are not used, which is something a kernel programmer would want]
* Victor Khimenko has claimed that "lots of nice features of C++ need support from run-time systems and using lots of space on stack. NOT what you want in kernel where even gcc run-time was stripped out (kernel is NOT linked with libgcc and it's done deliberately)". As I said, it depends on what in C++ you use. What features need support from run-time systems or excessive stack usage? Template instantiation? Or perhaps member function calls? I don't want to go into a polemic, so let me just say that a programmer may avoid excessive run-time system usage by carefully choosing which language and library features he's applying. He has added "you have only 4-5KiB on stack to play with and where heap is bonus (kmalloc, vmalloc and other things exist but should not be used if not REALLY necessary). I'm not sure if C++ is needed even in userspace but in kernel space it's not appropriate" I can think of a C kernel module that is intended to run on systems with large memory. Allocating 30 mb of RAM for a very special device. Objections? Besides, as I've said the memory is within the control of C++ programmer. C++ isn't Java, you can exercise very precise memory management. [And there would be applications where the g++ run-time's footprint wouldn't hurt]
Anyway, you can write a kernel with any language that's efficient and portable enough. If I were asked to design a lean kernel, I could go ahead with a generic RISC assembly platform rather than C. Not that one is available, but if it were it could be used instead of C. C is not the only systems programming language on earth; and obviously not the only language a hacker has to use.
* Alan Cox adds the following: "C++ is just a syntax wrapper over C with some bad exception handling included. It doesn't even do a good job on object orientation compared to stuff like smalltalk. People do object oriented programming in cobol. Its a programmer feature not a language feature."
Alan Cox sounds as if he hasn't followed the development of programming languages and compilers for the last 10 years. C++ used to be a syntax wrapper over C, a la the original cfront implementation. That has changed now, here is an excerpt from gcc info manual: " G++ is a *compiler*, not merely a preprocessor. G++ builds object code directly from your C++ program source. There is no intermediate C version of the program. " It occurs to me that you haven't read this part of gcc manual. Please do justice to your fellow hackers before you engage in an old-fashioned 'net religion war.
C++ is *not* (only) an object oriented language. Smalltalk and Java are. Please read the C++ FAQ, where you will find out that C++ is better defined as a "multi-paradigm" language which lets you code the way you like. OTOH, object-oriented programming *is* a language feature. For finding out why, I suggest you to examine the reference manuals of two languages: GNU Sather and Dylan. Briefly, object oriented languages are object-based languages + inheritance (that's how Booch defines them) facilitating better abstraction and code re-use among other things. You can emulate OO language features in a procedural language, which will only result in very clumsy and long programs.
C++'s emphasis is on generic programming, not OO programming. The best example of the utility of generic programming is C++ standard library itself, which includes the infamous STL. Another recent example is from the scientific computing community. From the description of Debian package blitz++. Description: C++ template class library for scientific computing Blitz++ offers a high level of abstraction, but performance which rivals Fortran.
Systems like blitz++ offer abstract but still very efficient services, something that is _not_ doable in C. Please read the blitz++ manuals if you'd like to comment on this, though.
Alan Cox continues "You also need to provide an interrupt safe, thread safe and smp safe lockless exception handling mechanism for the C++ exceptions. You can't really avoid that as you will want to do memory allocation and a memory allocation can and must fail gracefully."
If you're worried about the way g++ implements exceptions, don't use them. C++ doesn't require you to use them in your programs.
* Richard B. Johnson concludes the thread: 'I advise to not get trapped into the notion of the "correct" tool for a particular use. Just because you have become expert in C++, don't presume that it is the "correct" language for the kernel.
Even C has its shortcomings which have to be handled with assembly language extensions. A Master Carpenter has many tools and is expert with most of them. If you only know how to use a hammer, every problem begins to look like a nail. Stay away from that trap. It bytes (sic). '
So C gets to be the ultimate hammer, suffering from a few minor flaws only? There's no need to presume that any language is the "correct" language for kernel _module_ programming [which you're supposed to talk about]. If it does the job, it's usable. Let people try to implement their modules in C++; if the results are good enough then C++ gets to be one of the "correct" languages for kernel module programming. It just hasn't been done yet.
Only criticizing is not quite a fruitful activity. I offer Stepan Kasal to maintain patches for resolving the C++ reserved word conflict in linux source tree. Meanwhile, linux hackers might avoid introducing C++ reserved words into their programs; they're usually too generic and not very useful as names in module interfaces anyway.
Thanks,
PS: Many thanks to Kernel Traffic at linuxcare for providing thread summaries from linux-kernel mailing list.
__ Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: erayo@cs.bilkent.edu.tr www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |