On Sun, Oct 22, 2000 at 06:42:19AM -0400, Linux Kernel Developer wrote:
> Wasn't the original complaint that the kernel headers use C++
> keyword and thus prevent the writing of, at least some, modules in
> C++. I have written C++ code before that was as least as fast as
> comparable C code and more efficient in some ways. Whether this
> could be or not be reproduced in kernel code I do not know. So
> far I have done my kernel programming in C. However even if I or
> other programmers would like to give this a try it is my
> understanding we cannot because of the header situation. I think
> it is unfair to attack C++ kernel code that is unable to come into
> existence, at least without jumping through a bunch of hoops, due
> to external influences (i.e. the incompatible headers).
Yup, it's simple as hell to fix the occurences. Simply use an
interactive commandline find+sed expression and you should be happy.
It might take some time, but it's not complex.
And NOONE has forbidden the C++ lovers to do this. To my knowledge,
noone has done this, so far. WHY should the workload of this change
be laid on the programmers who don't feel any need for C++ in the
kernel?
I bet that all people who want to play with C++ in the kernel would
like this kind of patch. Cook it up, post the url to it somewhere and
bask in the glory.
> On a separate note. Isn't one of the philosophies behind Linux the
> idea of freedom. If people wish to try and program their modules in
Uhmmm, the original philosophy behind Linux was Linus not being able
to afford to pay for the legacy Unixen and Tannenbaum refusing to
accept any improvements to Minux... "I like free beer"... Of course,
realising that others might be in the same situation, he decided to
release the kernel under the GPL.
But the question is, do you REALLY think that it's a coincidence that
Linus is still a benevolent dictator? This isn't exactly the
developmentmodel of total freedom, isn't? The Mozilla-model comes
closer, and I bet there are even more open projects. But do they
work as good? Nope.
But the GPL gives you every right to change this. You're fully free to
fork the kernel WHENEVER you like. You can then change the goals of
your new kernelproject completely and make it fully C++, if you like.
But I doubt you'd succeed. Not because of your skills (I know nothing
about them), but because C++ isn't a one-concept language. Is an
aggregate of every damn new, cool programming concept, barring
functional programming. This simply doesn't cut it in a kernel.
If you succeed, however, I wish you good luck.
> C++ for whatever reason, be it porting from existing code or to object
> orient their code, should they be free to do so. If the header
Yup. And I want to try out my modules coded in Visual Cobol, APL,
and PL/I. Oh, and I want to rewrite ext2fs to use Befunge.
> situation is true, which I am not sure of since I have not tried to do
> C++ programming in kernel code, then people aren't free to write
> modules however they wished. Seeing as fixing the headers should be
As long as they don't have any delusions that those modules will
be accepted into the mainline kernel, then yes.
> rather trivial and probably is the right thing to do anyway (using
> existing language keywords is a bad idea) I do not see why this same
I bet that a lot of the variable-names we use are keywords in this or
that language.
> flame war must erupt every time the header situation is brought up.
> Its not as if C++ code would all of the sudden popup in the kernel
> core forcing everybody to use C++. At best a driver here and there
No, this is an "at worst" situation. Fast corruption can be dealt with
efficiently; just return to an earlier kernel and fork from there.
Slow corruption is another matter altogether.
Then again, I trust our benevolent dictator's judgement. I'm pretty
confident he won't let the kernel become contaminated.
> might start using it and its continual usage would depend on if its
> implementation is successful or not. And those drivers themselves are
> extremely likely to be self-contained thus not affecting anybody
> else's kernel code.
If C++ really is what we save us all from an uncertain destiny and
the lack thereof is what keeps every good kernelhacker in existance from
participating, then I'm pretty confident that the merits of a C++
kernel would pretty fast become obvious. Devote one of your servers to
be a CVS-server for the C++ kernelbranch and let people hack away. For
every single kernelrelease you then release a patch-set that contains
the difference between the two trees. This isn't particularly hard.
You could as Larry McVoy for BitKeeper if you like, if you need
something better than CVS.
Good luck!
/David Weinehall
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
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:19 EST