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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:28 EST