Messages in this thread |  | | Date | Sun, 22 Oct 2000 13:30:20 +0200 | From | David Weinehall <> | Subject | Re: [Criticism] On the discussion about C++ modules |
| |
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/
|  |