[Criticism] On the discussion about C++ modules

From: Eray Ozkural (erayo@cs.bilkent.edu.tr)
Date: Sun Oct 15 2000 - 08:34:09 EST


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

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

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


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/

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:28 EST