"Jeff V. Merkey" wrote:
>
> Tell you what. You should go look into the Chorus or TMOK projects that
> are based on C++ and pester them.
Fine. I don't want to waste my time with somebody else's crap though!
> Next you'll be telling me that IDL
> and Corba stubs in every layer of the OS are in order and won't hurt
> performance.
No, I won't! I don't believe in Corba.
> I did this OOM mental mastrubation excercise with the USL
> folks 7 years ago at Novell and sat in lots of design reviews of C++
> kernel code for Unixware and we had so many offsites on this crap, I saw
> the NOvell campus about once every two weeks in between political
> meetings with Art Sabsevitch and his USL buddies.
Too bad for Novell coders.
You know, there are other factors in these grand C++ failures. It's
kind of a sociological disaster. Once C++ is in the play, I guess
developers trust on it so much that they _forget_ about important
design elements. In a kernel, you _have to_ think about a zillion
"fast paths". That means it's not eligible to use exceptions or
virtual function calls at a low-level function, and other things as well.
[C++ is not sort of a magical entity that will do the thinking for you,
it's just another programming language]
There is a strong backup to this argument. When you're writing in C++,
you can resort to a style that's very similar to C. If you write only
generic procedural code, your program becomes just a generic C. Throw
in a few object-based abstractions, and the cake's done. And if you
_really_ want to code the whole kernel in C++, you have to be very
careful because the services the kernel offers and the implementation
of those services are not the same thing. At the very low level, you'll
probably want to use a style that's *just like* C and assembly. (Of course,
you can make use of C++'s more flexible syntax and strong type-checking)
At the higher level, you can present a more abstract interface to *module*
developers. Of course, you have to show them how to write a module and
supply some utility routines, too. Overall, writing a clean and efficient
C++ kernel is a daunting task.
> We wasted two years
> of time, spend 375 million dollars on the C++ modular kernel projects,
> and ended up with a pile of crappy Chorus code that was unsellable and
> shitty. You should go over to the Chorus group with your ideas about
> C++ kernels. They will listen to you because they believe their own BS
> about C++ kernel development -- you'll be right at home...
Chorus group does wrong because of other things, too. There is no
real disttributed OS on the planet, and you're contrasting Linux *module*
development with the full-scale development of another system.
It's not that I love BS, I'd written to him asking for some advice
(not on C++) and he hadn't replied. :(
[As I told somebody else]
I am not advocating using C++ for writing base Linux kernel code.
Let it remain C as you like it. I'm just telling that
* you can't prevent people from writing C++ linux modules as they like
* you are making unfair criticism of C++ language
My purpose is not to engage in a net religion war. I only want to
clarify technical aspects of a dispute concerning platform choice
for kernel module development.
Thanks,
-- 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 : Mon Oct 23 2000 - 21:00:11 EST