Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

C++ In The Linux kernel

timothy posted more than 9 years ago | from the kitchen-sink-and-jacuzzi dept.

Programming 850

An anonymous reader submits "A researcher at Reykjavik University Network Laboratory (netlab.ru.is) has just released a Linux patch allowing for complete kernel-level run-time support for C++ in the Linux kernel, including exceptions, dynamic type checking and global objects (with constructors and destructors) The implementation is based on the C++ ABI in GNU g++, but contains various kernel level optimizations, that reduces the cost of throwing exceptions by an order of magnitude, thus making C++ exceptions viable in several scenarios. Furthermore, the Linux module loader is extended to handle weak symbols in C++, so that dynamic type checking is reduced to a pointer comparison, in contrast to string comparison."

cancel ×

850 comments

Sorry! There are no comments related to the filter you selected.

I don't know what this article is about, but... (0, Troll)

Ass, Ltd. Ho! (714400) | more than 9 years ago | (#10647302)

I didn't read the article, or even the summary, but i can tell you one thing:

Slashdot moderators are all fucking cock suckers!

FP BITCHES!!!! SO FUCK IT ALL TO HELL!!!

YASSER ARAFAT IS DEAD (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10647396)

And all you Linux fags can do is talk about C++??

Re:YASSER ARAFAT IS DEAD (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10647473)

He isnt dead yet (well at least not officialy) but then again he was dead the moment he took power.

nice (5, Funny)

Anonymous Coward | more than 9 years ago | (#10647303)

how long until c# is supported?

Who cares? (3, Funny)

Anonymous Coward | more than 9 years ago | (#10647578)

My VB kernel works just fine for me.

so... (0, Insightful)

Anonymous Coward | more than 9 years ago | (#10647306)

for us non-developers, this means what?

Re:so... (2, Insightful)

yecrom2 (461240) | more than 9 years ago | (#10647336)

for us non-developers, this means what?

Not a dang thing.

Re:so... (0)

Anonymous Coward | more than 9 years ago | (#10647362)

hell, it don't mean diddley squat to 99.9% of the so called "developers" out there...

More Confusion (4, Funny)

OverlordQ (264228) | more than 9 years ago | (#10647309)

So what will we say the kernel is written in . . C? C+? CKernelRun?

Re:More Confusion (1)

Short Circuit (52384) | more than 9 years ago | (#10647425)

C/C++.

And as an armchair advocate of distinction between the two, that scares me.

Re:More Confusion (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10647646)

Anybody who comes to our interviews and states or referrs to C/C++ is not selected. Period. Two distinct languages people.

Re:More Confusion (5, Funny)

M51DPS (757403) | more than 9 years ago | (#10647465)

The kernel will be written in Java for more cross-platform compatibility.

Re:More Confusion (0)

Anonymous Coward | more than 9 years ago | (#10647678)

N00b, we all know l337 coders use JavaScript and XUL for cross platform compatibility.

Re:More Confusion (4, Funny)

Tumbleweed (3706) | more than 9 years ago | (#10647509)

CKernelRun?

a) CKernelCrash
b) CKernelPatchNotGetAcceptedByLinus

One or the other, I'm sure.

Re:More Confusion (3, Funny)

aled (228417) | more than 9 years ago | (#10647592)

that's an exception:

throw new ExceptionPatchNotAccepted("Linus");

C++? (5, Funny)

Anonymous Coward | more than 9 years ago | (#10647315)

Good now I can fire up my good old visual basic and hack the kernal with COM.

Re:C++? (3, Funny)

npietraniec (519210) | more than 9 years ago | (#10647348)

and I was just thinking... I wonder how long until someone makes a "I want to use visual basic" comment. That didn't take long. hilarious.

Re:C++? (2, Funny)

FecesFlingingRhesus (806117) | more than 9 years ago | (#10647382)

No no one would ever want VB, now C# or java on the other hand.

Re:C++? (0)

Anonymous Coward | more than 9 years ago | (#10647477)

Java, NO!
C# I don't know enough about. It might be possible, if you didn't use most of its features.

Re:C++? (1)

FecesFlingingRhesus (806117) | more than 9 years ago | (#10647503)

It was actually just a joke. I don't believe either have their place in the Kernel.

Re:C++? (0)

Anonymous Coward | more than 9 years ago | (#10647494)

I would want a VB kernel, you assholio!

Po0p dick is a result of anal sex!

Re:C++? (2, Funny)

Kethinov (636034) | more than 9 years ago | (#10647571)

Imagine the enormity of newbie kernel hackers if such a thing were beieved to be possible...

I can imagine a post to usenet now...
Subject: this damn thing wont compile

omg why are none of my win32 api calls working this sucks this will never be better than windows
And the ensuing reply...
Subject: Re: this damn thing won't compile

Uh huh. Well. It won't compile because your api calls are, uhm, frozen. Yeah. You need to unfreeze them. There should be a blue liquid in the trunk of your car called antifreeze. If you drink it all, and I do mean all of it, you'll be able to unfreeze your api calls.

Have fun.

Re:C++? (2, Interesting)

Electroly (708000) | more than 9 years ago | (#10647554)

Interestingly, the driver interface in Mac OS X actually is COM. With QueryInterface() and everything.

Alright!! (5, Funny)

21chrisp (757902) | more than 9 years ago | (#10647326)


I'm sure the kernel developers will LOVE the idea of putting C++ in the kernel.

May you burn in hell, Yassir... (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10647616)

for betraying your people. Clinton tried to broker peace between Israel and Palestine, and despite historic Israeli concessions you chose violence. God will not deal kindly with you. Good riddance.

Yay! (3, Insightful)

stonecypher (118140) | more than 9 years ago | (#10647337)

It's about fucking time. Now maybe we're on the path to a bullet for killing those shallow arguments about C++ somehow being majorly slower than C, as opposed to people just not knowing the costs of C++ features.

Re:Yay! (0)

Anonymous Coward | more than 9 years ago | (#10647398)

And just not knowing the costs of C++ development!

Re:Yay! (5, Informative)

apankrat (314147) | more than 9 years ago | (#10647532)

It's not the slowliness, it's the obscuirty and the lack of control over the binary code size it introduces. Something as simple as 'a == b' may easily add few KB to the kernel.

If you think it's OK, you obviously haven't been involved in kernel or embedded development. If you say one should be careful what features of C++ he uses and not to use this and that, I say one should learn proper C skills instead.

Re:Yay! (5, Insightful)

Lally Singh (3427) | more than 9 years ago | (#10647621)

Embedded dev is now often C++ based. It's all about making sure you have devs who have a clue.

Anyone writing a == b should notice that a & b aren't primitive types.

Re:Yay! (2, Insightful)

SpaceLifeForm (228190) | more than 9 years ago | (#10647655)

It doesn't matter if the developers have a clue. Linus has repeatedly said no.

Go fork your own kernel then. Good luck.

Re:Yay! (0)

Anonymous Coward | more than 9 years ago | (#10647634)

Please describe a case where in C++, 'a == b' would add to the size of the code. Presumably, you are referring to overloading the == operator, in which case the equivalent C would require a function that does the same thing, taking up the same size.

But the question remains... (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#10647342)

can it run Linux?

What about Java in the kernel? (0, Interesting)

Anonymous Coward | more than 9 years ago | (#10647349)

n/t

Exceptions are suddenly viable? (2, Insightful)

gbjbaanb (229885) | more than 9 years ago | (#10647350)

oh dear, again someone who doesnt; understand that exceptiosn are designed never to be thrown. If they were everyday occurrences, then they wouldn't be, well, exceptional.

Unlike some languages who use exceptions for events that you expect (like End-of-file) and poor programmers who think that because they're there, they must be used all the time, for everything, exceptions are a defensive programming measure to ensure that the things that should never, ever happen, are handled gracefully if they do.

Re:Exceptions are suddenly viable? (1)

21chrisp (757902) | more than 9 years ago | (#10647364)

True. If an exception is thrown, it's mostly likely a program-halt condition. Which you obviously don't want in a kernel.

Re:Exceptions are suddenly viable? (1)

toggles (560010) | more than 9 years ago | (#10647390)

as opposed to a kernel panic?

Re:Exceptions are suddenly viable? (1)

21chrisp (757902) | more than 9 years ago | (#10647479)

Similar, but an exception allows for a gracefull exit before the *crash* occurs. This is useful for apps because it will save data and exit normally (without memory leaks) where a true crash couldn't avoid this. But at the kernel level both will result in the same thing (at least I would think). I suppose a kernel exception might be able to go as far as shut down your computer rather than lock it..

Re:Exceptions are suddenly viable? (0)

Anonymous Coward | more than 9 years ago | (#10647514)

If it gets as far as a sync(), I'm happy.

On Linux, sync() seems to wait until the buffers are flushed.

Re:Exceptions are suddenly viable? (2, Informative)

Lally Singh (3427) | more than 9 years ago | (#10647534)

exceptions are a great way to structure your error handling.
they're an in-language mechanism similar to signals, only that they don't have the brain-deadedness of them.

Hell, just having smart pointers whose destructors are properly called on the stack unwind is enough.

Re:Exceptions are suddenly viable? (0)

AuMatar (183847) | more than 9 years ago | (#10647612)

I'd have to disagree. Exceptions move the error handling away from the code causing the error, making it difficult to tell exactly what call caused the error, and breaking up the logical flow of the program. The C code

error=do_foo()
if(error) //handle error and return if error unfixable
do_next step

makes it easy to tell what exactly caused the error. It also makes logical sense- an error occurs, you fix it immediately, life goes on. The exception based code:

try
do_foo()
do_next_foo()
do_foo3()//continue on here for 10 lines
catch a //handle a
catch b //handle b ...

This is horrible. You don't know what had an error. You also lose the flow of the code- the physical separation makes it much more difficult to understand. The ONLY advantage of this is not needing to return an error code, allowing do_foo to return a value. It would have been a far better idea to just let C++ allow multiple return values from a function instead (so a function could be declared to return 2 ints, for example). This would have been a very useful feature. Instead we get this mistake called exceptions.

Re:Exceptions are suddenly viable? (2, Informative)

BCoates (512464) | more than 9 years ago | (#10647555)

I think that's a bit backwards; ordinary user applications can just terminate ungracefully, and the kernel will clean up after them (close all open files, free memory, etc) if a section of kernel code runs into a problem, it has to roll back everything to a sane state before returning to the caller if there's going to be any hope for the entire kernel to keep going (without leaking). I believe right now the linux kernel mostly does this with an elaborate system of gotos and return value checking that's pretty much exactly what C++ stack-unwinding does, just by hand.

Re:Exceptions are suddenly viable? (4, Informative)

Lally Singh (3427) | more than 9 years ago | (#10647600)

Nope. It's a condition that the throwing code couldn't handle. Someone else can handle it.

Classic example: a method calls another that calls another that calls openfile() for a temp file, which fails. the lower two methods don't care, and the toplevel one can give the user a proper error message and clean up.

People wonder why software is so hard to test, does so poorly on error handling, yet complain whenever we add mechanisms to languages to help.

I take exception... (4, Informative)

IceAgeComing (636874) | more than 9 years ago | (#10647511)


I've only written one linux driver, so I'm no expert, but I can think of situations where exceptions can be helpful for device drivers.

Take, for example, a game controller or other hardware device that can become unplugged at any moment. It's useful to have an elegant way of handling this uncommon occurrence.

Exceptions are a useful way to separate uncommon sanity checks from the rest of your code, so you're not forced to use ugly nested conditionals.

Re:Exceptions are suddenly viable? (1)

slashrogue (775436) | more than 9 years ago | (#10647526)

That may be true in a lot of cases, but in the operating system? You can't guarantee ANYTHING is what you want it to be.

Re:Exceptions are suddenly viable? (4, Informative)

cout (4249) | more than 9 years ago | (#10647609)

Oh dear. Another person who thinks that exceptions should never be thrown.

If exceptions were never meant to be thrown, they wouldn't be in the language. Exceptions are an abstraction for dealing with exceptional conditions -- conditions that do not normally occur, but can occur. At the expense of some additional complexity, they make error checking a little simpler and less bug-prone. When (not if -- assuming you are a believer in Murphy's law) those exceptional conditions occur, your program better be able to handle them correctly.

You are right that some people do use exceptions when not appropriate. Exceptions are (generally) not appropriate for exiting loops, for example. But they are more than appropriate for out of memory conditions, out of disk space conditions, etc.

The reason they are not viable performance-wise is not because they are too expensive to throw; it is because they are too expensive when they are never thrown at all. There's generally a 5-10% performance hit just from having code that might possibly throw an exception, depending on your compiler's implementation. The numbers on the netlab page are for throwing exceptions, unfortunately; I would be interested in seeing if they got a performance benefit when exceptions are not thrown. Guess I'll have to dig to find a copy of the paper.

Re:Exceptions are suddenly viable? (0)

Anonymous Coward | more than 9 years ago | (#10647658)

Exceptions are useful for libraries where the problem can't be dealt with by the library code. You document the exceptions that can be thrown by a class and so the app can handle them.

Re:Exceptions are suddenly viable? (1, Troll)

Waffle Iron (339739) | more than 9 years ago | (#10647672)

oh dear, again someone who doesnt; understand that exceptiosn are designed never to be thrown.

I disagree. Exceptions are appropriate in many cases for conditions like "file not found" errors. These can be expected to happen in the ordinary operation of the program.

The whole advantage of exceptions is removing the need for complex deeply-nested if (errorcode) statements or error-prone goto exit jumps. It also removes the dilemma of functions returning useful information and an error code at the same time (without exceptions APIs usually provide a messed-up combination of in-band and out-of band information).

If you never use exceptions, you have to deal with all of that garbage even if the language is prepared to help you. Why not use the feature to clean up your code? Handle errors in a few choice spots where you're prepared to deal with them, not on every alternate line of your app.

Stillborn. Seriously (3, Funny)

apankrat (314147) | more than 9 years ago | (#10647355)

Java on other hand ...

Or better yet - Brainf*ck, my personal favourite :)

First step... (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#10647356)

All right, this is great news. We are one step closer to modernizing the kernel, allowing an object-oriented design. This is exactly what *nix in general needs, to be keep up with emerging trends in networking/hardware.

ob commect (1)

Mr Smuggles (816430) | more than 9 years ago | (#10647361)

but will it run on linux? :P

And... (-1, Redundant)

SealBeater (143912) | more than 9 years ago | (#10647365)

This means what, exactly?

SealBeater

Great news! (0)

Anonymous Coward | more than 9 years ago | (#10647369)

This can only be viewed as a good thing.

I know that code I produce in C++ is by far more sophisticated, and of a much greater quality standard than what I could produce in C in a similar time frame.

I hope that this will be the beginning of some new more sophisticated features for Linux!

Re:Great news! (3, Insightful)

AuMatar (183847) | more than 9 years ago | (#10647654)

Thats because you're used to C++. I know that code I produce in C is by far more sophisticated, and of a much greater quality than what I could produce in C++ in a similar time frame (unless I used the C subset of C++, which basicly means I was writing C).

Now if you were to start a new kernel entirely in C++, that'd be fine. The use here would be to mix the two *shudder*. No thanks. You then have a problem where the C++ people can't understand the C code, and the C people don't understand the C++ code. Its a maintenance nightmare. Just wait til the first patch that requires changing C and C++ parts. It'll be ugly.

Its much better to pick 1 language for a project and stick with it, or do a total rewrite. Mixing the two will just cause problems. Luckily, this patch has near 0 chance of being taken into the kernel.

Great news, I hop (4, Interesting)

Anonymous Coward | more than 9 years ago | (#10647371)

That's really awesome news, but I just can't imagine it being accepted in the mainline branch. Many figureheads in the linux kernel group are anti-C++ enough to probably veto this effort. (If "anti" is too strong, then at least I'll safely claim they're not "pro C++".)

It'd sure be nice though...

Perl (0, Funny)

Anonymous Coward | more than 9 years ago | (#10647374)

When can I submit my Perl patches to the kernal? I am waiting for that.

full article text, just in case (2, Informative)

Anonymous Coward | more than 9 years ago | (#10647378)

C++ in the Linux Kernel

We have implemented a complete kernel level run-time support for C++ in the Linux kernel. In particular our run-time support enables the full use of C++ exceptions in the Linux kernel, but notably also includes support for global constructors and destructors, and dynamic type checking. Our kernel level support is based on open source commodity components, specifically the GNU gcc/g++ compiler and its exception implementation, the C++ ABI version independent standard interface.
C++ runtime support for 2.6.6 (Last update 27 october 2004)
C++ runtime support for 2.6.9 (Last update 27 october 2004)

Using the C++ runtime support for Linux
Installing the C++ runtime support for Linux

The code is installed by applying a patch to the Linux kernel and enables the full use of C++ using the GNU g++ compiler. Programmers that have used C++ in Linux kernel modules have primarily been using classes and virtual functions, but not global constructors. dynamic type checking and exceptions. Using even this small part of C++ requires each programmer to write some supporting routines. Using the rest of C++ includes porting the C++ ABI that accompanies GNU g++ to the Linux kernel, and to enable global constructors and destructors.

The implementation of the C++ ABI is based on the implementation provided with the source of the GNU g++ compiler. We modified it to run in kernel space, and performed optimizations that reduces the cost of exceptions and dynamic cast considerably. Our paper contains thorough explanations of these optimizations. The cost of throwing an exception one level on a 990 MHz Intel Pentium is around 12-13 micro seconds in the plain GNU g++ implementation, which we reduced to 2.1 micro seconds by modifying the runtime library, including unwinding the stack in one phase, and caching information on exception paths. In contrast the cost of a trivial printk operation -- printk("Error\n") -- is 18 micro seconds.

In addition, we modified the linux kernel module loader to handle C++ weak symbols correctly. GNU g++ associates with each class a type information object that encodes the type of the class as a mangled string and puts a pointer to this object in the virtual table for the class. GNU g++ uses weak symbols to reduce the dynamic type checking to a pointer comparison, thus avoiding the more expensive string comparison. Each time a class, containing virtual functions, is used in a source file, GNU g++ generates the virtual table, type information object and type name string as weak symbols and the user space linker ensures that there is only one copy of this object, which renders the simple pointer comparison sufficient. However, the kernel module loader, which in the 2.6 versions of the kernel is exclusively in kernel space, does not handle these weak symbols correctly and always relocates references to weak symbols to the weak definition within each object file that is being loaded. Therefore multiple type information objects may exist for the same class and pointer comparison becomes insufficient when doing dynamic type check across kernel modules. To avoid this overhead we have modified the kernel module loader to handle these weak symbols; the first time a weak symbol is encountered it is added to the symbol map, and on subsequent encounters the relocation is done to the first symbol.

Paper:
Exceptional Kernel: Using C++ exceptions in the Linux kernel
Halldor Isak Gylfason, Gisli Hjalmtysson
Submitted for publication October 2004 abstract

Please direct bug reports, questions and comments to {halldorisak at ru dot is}

RMS (5, Funny)

zoeith (785087) | more than 9 years ago | (#10647381)

RMS is probably turning over in his grave... oH! wait he's not dead!

Progress (4, Interesting)

caseih (160668) | more than 9 years ago | (#10647384)

Say what you will about C++ being slower and more bloated than C, but I think this is a huge leap forward. I doubt Linus will accept it anytime soon as an official patch, though. If they have succeeded in making exceptions quick, I think C++ has a real place in the kernel. C++ offers the ability to have better type safety and more modular apis and interfaces to the kernel. For example being able to develop a new device driver inheriting from a nice base class is a good idea.

Anyway, this is a neat hack and I look forward to seeing what comes of it.

Re:Progress (4, Informative)

alienw (585907) | more than 9 years ago | (#10647488)

Nothing will come out of it, for the simple reason that C++ does not belong in any kernel. In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.

The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.

Re:Progress (5, Insightful)

fitten (521191) | more than 9 years ago | (#10647585)

In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.

Yeah, who wants a common driver API for video, network, or sound cards...

Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...

The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.

Yes, a kernel is more difficult than a word processor, but that doesn't mean that implementors must implement stupid C++ code. You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.

Re:Progress (1)

Lally Singh (3427) | more than 9 years ago | (#10647641)

Of course not. That's why we use assembler... oh wait...

Besides, the abstractions are already there, only they're not supported by the language. Look at device drivers: they're polymorphic classes, only that there's no checking that the compiler can do.

Re:Progress (0, Flamebait)

Vlion (653369) | more than 9 years ago | (#10647684)

hahaha.
You _don't_ use C++ that much, evidently.
And, you OBVIOUSLY havn't read Linux kernel code.
Obfuscation and opacity are its hallmarks.

I'll read a LISP kernel before I read a C kernel, given the choice.

Re:Progress (1)

pchan- (118053) | more than 9 years ago | (#10647687)

while i generally agree with you, here is a special case:

the haiku os [haiku-os.org] (formerly OpenBeOS) kernel is partially written in C++, especially the BFS filesystem implementation [sourceforge.net] . but there's a catch! they don't use many of the features of c++ that make it bad for just these kinds of things. no exceptions, no virtual functions, no STL, none of that other nonesense that c++ does behind your back.

Re:Progress (4, Insightful)

IceAgeComing (636874) | more than 9 years ago | (#10647691)

In a kernel, all the code needs to be transparent,

That got a chuckle from me. I know what you meant, but after looking at the following (randomly chosen :) block from the device driver grip.c, I wonder just how "transparent" it is:

if ((((u ^ v) & (v ^ w)) >> 1) & ~(u | v | w) & 1) {
if (i == 20) {
crc = buf ^ (buf >> 7) ^ (buf >> 14);
if (!((crc ^ (0x25cb9e70 >> ((crc >> 2) & 0x1c))) & 0xf)) {
data[buf >> 18] = buf >> 4;
status |= 1 > 18);
}


The simple reason for that is that otherwise the kernel would be unpredictable.


Point taken, but I hope you're open to the idea that C++ classes can be written that avoid these problems. In particular, it's relatively easy to define your own memory management scheme. This could be confusing to some (redefinition of new and delete would not be obvious in other parts of the code), but C++ has some nice features that facilitate scalability. I'm sure you'll agree that maintaining such a complicated thing as a cross-platform kernel can use some more sophisticated tools for software development than what C provides.

bah humbug (-1)

Anonymous Coward | more than 9 years ago | (#10647385)

Any thing C++ can do, C can do better.

All these Java/C++ types should learn the beauty of asm and C.

Sorry to break it to you... (2, Informative)

RAMMS+EIN (578166) | more than 9 years ago | (#10647392)

Linux doesn't want any C++, so as long as he's at the top, it likely won't get far. And I think that's good, given the state of C++ in gcc (hint: slow and memory-intensive compiles, generating subobtimal code).

But I'll shut up. I've pretty much turned my back on C and C++ anyway.

Re:Sorry to break it to you... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10647414)

lol. One day he'll use C++, and then we'll see what happens to the kernel.

He sure as hell isn't going to start writing the kernel using Java now is he!

Re:Sorry to break it to you... (2, Funny)

Anonymous Coward | more than 9 years ago | (#10647460)

Hello.

My name is Linux Torvalds, and I pronounce "Linus" "Linus".

Who cares? (5, Informative)

Percy_Blakeney (542178) | more than 9 years ago | (#10647407)

I really don't see the use in porting these features to the Linux kernel -- they'll never be used in any mainstream kernel release. Linus has stated many times that he doesn't particularly care for C++ in the kernel [tux.org] :

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

* the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either

* (a) looking for problems
* (b) a C++ bigot that can't see what he is writing is really just C anyway
* (c) was given an assignment in CS class to do so.

Feel free to make up (d).

Re:Who cares? (2, Interesting)

Kethinov (636034) | more than 9 years ago | (#10647492)

I agree entirely. C++ in the Linux kernel is a largely bad idea.

I am all for the kernel remaining C forever, but just for the sake of curiosity's fancies, I wonder how much better Objective-C would be as a high level yet still high performance solution as opposed to the messier C++?

Objective-C (1, Informative)

Anonymous Coward | more than 9 years ago | (#10647540)

Worse than C++.
Objective-C is too dynamic, and all objects are heap objects.

Re:Who cares? (1)

Lally Singh (3427) | more than 9 years ago | (#10647507)

Hmm, so, was there ever an explanation to these?

the first arg has no explanation.
the second -- what hidden memory allocations??
third: you can write in ASM too, but that doesn't mean you should.

Re:Who cares? (1, Interesting)

Anonymous Coward | more than 9 years ago | (#10647572)

Fact is, its harder to write robust code in C than it is in C++.
Fact is, we ain't in 1992 anymore. Our computers can take the miniscule slowdown compared to the better code.

His point 1 is unproven.
His point 2 is wtc? Was he thinking Java here?
His point 3 has minimal validity; but still has lots of unproven sitting behind it.

His point (a) is bigoted.
His point (b) is bigoted.
His point (c) is asinine.

Haha! Now I'm a troll for dissing Linus!

Re:Who cares? (1)

pyrrho (167252) | more than 9 years ago | (#10647583)

memory behind your back... not really, you can

(0) on exception: sure, don't use C++ exceptions in the kernel. no need.

(1) control the allocation or even, gasp, not use classes, which are just one idiom available in C++.

(2) re: writing in C anyway, C/C++... yes, why not use C++ as a better C... or is the "const" keyword evil.

A C bigot... perhaps?

Re:Who cares? (2)

homebrewmike (709361) | more than 9 years ago | (#10647623)

Alternatively, someone could try the patch, and re-evaluate it.

Computer Science isn't a religion, it's evolutionary. If the "C++ patch" works great, and makes things easier, so be it. If not, it gets tossed out.

If it is good, and it is rejected, then what's the point of Open Source?

"The fact is..." he's out of touch (3, Interesting)

devphil (51341) | more than 9 years ago | (#10647624)


Anyone who claims with a straight face in 2004 that "C++ compilers are untrustworthy" is trolling. Sorry, rabid penguin lovers.

I love it when language bigots forestall any reasonable discussion by preemptively accusing anyone who disagrees with them of being a language bigot. Slashdot, of course, believe that Linus can do no wrong, so none of it ever applies to him...

After having conversations with him myself, I can state my honest belief that Linus doesn't understand how to use C++, and will simply assert that "it's just C anyway" no matter how many times he's proven wrong. He's a smart guy, but he's got his blinders on in some respects.

fantastic ... (4, Funny)

Anonymous Coward | more than 9 years ago | (#10647432)

what an incredibly awesome idea!!!

i can't wait to try and debug virtual functions, copy constructors, and polymorphism over JTAG or BDM!!!!

man thats gonna be fun ... my hats definitely off to this academic you have definitely spent your time wisely!!!!

i always found C causes to much clutter in the linux kernel ... a real language will do us all good ...

keep an eye for this in 3.0 ...

Jim

.... so can we compile the kernel (2, Interesting)

TheRain (67313) | more than 9 years ago | (#10647435)

using the kernel now? :)

Joking aside, this is cool. Runtime compiling makes conceptual sense in an open source operating system running mainly open source software... though it will surely add to load times. It adds to the openess of open source by keeping the source editable straight up untill run-time and, so, encourages keeping source code and editing source code... being that it is immedietly executable, given it was coded correctly of course ;)

Re:.... so can we compile the kernel (1, Informative)

Anonymous Coward | more than 9 years ago | (#10647599)

RTFA. This is not about a compiler in the kernel, it's about using C++ instead of C.

Re:.... so can we compile the kernel (1)

PugMajere (32183) | more than 9 years ago | (#10647638)

That brings a whole new meaning to the term, "self-hosting"

Exercise in Obfuscation (0, Troll)

drewzhrodague (606182) | more than 9 years ago | (#10647439)

Sounds like an exercise in obfuscation. How will SCO handle this?

Re:Exercise in Obfuscation (0)

Anonymous Coward | more than 9 years ago | (#10647500)

Probably by saying that they did it first and these guys owe them money.

SCO will do: (0)

Anonymous Coward | more than 9 years ago | (#10647524)

Like they handle everything else.

* A nice handshake
* Grease up the 10 feet pole
* Insert it in

yyeeaaaaahhhh (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10647441)

C++ is for queers that are too affraid to use a real language like C.

F1R$t P0$t!!!!!!!! BiTcHeS!!!!!

C++ (4, Interesting)

bsd4me (759597) | more than 9 years ago | (#10647455)

I'm not sure if many people remember, but there was a short time when the kernel source was compiled with g++, even though the source was plain C.

IIRC (memeory very hazy, though), it lasted about a month in 1992 or 1993, and it had something to do with type-safe linking(?).

Here's what's coming up! (3, Funny)

Le Marteau (206396) | more than 9 years ago | (#10647458)

Support, within the kernel, for IE^H^HMozilla! It'll be perfectly safe! Trust us!

Exception-handling changes relevant for g++? (3, Interesting)

Monkius (3888) | more than 9 years ago | (#10647468)

Kernel aside, I wonder if G++ developers out there have any comments on these guys' exception-handling changes?

Would they be applicable to the user-space runtime?

Sorry.... Darl owns that too. (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#10647474)

SCO owns C++

http://techupdate.zdnet.com/techupdate/stories/m ai n/0,14179,2877578,00.html

Are you serious? (0, Offtopic)

KinkifyTheNation (823618) | more than 9 years ago | (#10647484)

Just this afternoon I pondered if Linux supported C++ like this. With Slashdot I don't have to go out of my way and do things like being social to get things answered anymore. Thanks, Slashdot, for ensuring my nerdyness!

interesting, but not very useful (4, Interesting)

cout (4249) | more than 9 years ago | (#10647487)

Any kernel project that uses C++ is most likely doomed to be an experimental project and will most likely never be included in the kernel. IMO, there's good reason for that, too. The added complexity just doesn't outweigh the benefits of using C++ over C.

In fact, there was a good post on kerneltrap not to long ago about C++ inside the linux kernel:

http://kerneltrap.org/node/view/2067

Worth a read if you've got a few minutes to burn.

great! (2, Funny)

pyrrho (167252) | more than 9 years ago | (#10647504)

but don't use runtime type checking in the kernel please.

or exceptions.

So it has come to this. (0)

Anonymous Coward | more than 9 years ago | (#10647541)

Linus is rolling in his grave.

A good hacking exercise, but... (1)

Anonymous Coward | more than 9 years ago | (#10647546)

Every day newer appliances are thrown in the market without Linux drivers; a C++ kernel won't help much in avoiding this. *Please* if you have enough resources/knowledge go test some hardware and help developing drivers for unsupported stuff.
In other words, put the efforts where they're most needed.

Re:A good hacking exercise, but... (2, Insightful)

fitten (521191) | more than 9 years ago | (#10647615)

In other words, put the efforts where they're most needed.

I thought F/OSS (and Linux) was all about innovation and exploration... Sure, there are lots of things that F/OSS projects need (not the least of which is some QA effort), but it also needs folks like these people who are out doing cool stuff, even if it isn't necessary practical (or even considered practical by the 'masses' or the 'powers that be').

The true nature of C++ :) (5, Interesting)

kompiluj (677438) | more than 9 years ago | (#10647595)

C++ was designed to be the language of choice for modern operating systems, meant to replace C. This is main reason why every decision was made with efficiency in mind (no automatic virtual functions, no garbage collection, and, oh yes!, the infamous: pointers and goto). And of course C++ is fast. Maybe it loses by hair's breadth with C but surely wins with Java by great margin. And don't tell me about JIT, do some homework.
I think trying to incorporate C++ into Linux kernel is a good decision, giving more vitality to Linux and allowing it to differentiate better from the traditional UNIX systems - but that's only my 0.02 Euro.

But why should C++ be used in the Linux kernel? (2, Interesting)

master_p (608214) | more than 9 years ago | (#10647628)

The article says that they managed to support C++ in the kernel. Well, that's sweet as an accomplishment. But what are the benefits? many parts of the kernel are already object-oriented, in the form of manually written vtable structs and object structs that have pointers to those vtables. I just don't see a reason for C++ in the kernel. Maybe someone that knows more on this can enlighten us.

Windows kernel allows C++ (0)

Anonymous Coward | more than 9 years ago | (#10647631)

<troll>
While the NT kernel itself is written in C, and Microsoft doesn't officially support C++ for drivers, many people have figured out how to write Windows drivers in C++. It's about time Linux caught up!
</troll>

Sounds good...for some (0)

Anonymous Coward | more than 9 years ago | (#10647656)

just don't try it on a 486 or for that matter a P1 or P2, unless you have gobs of ram and time to burn. Having smp with P1s or 2s might help. But how many cheapo multi-processors are still around? C might be out of date, but atleast it is quick.

You're going to kill Stallman (2, Funny)

TheKubrix (585297) | more than 9 years ago | (#10647676)

Or at least drive him (more?) insane! [gnu.org]

Reviving a joke... (2, Funny)

ari_j (90255) | more than 9 years ago | (#10647690)

The good news is that we have a new renewable power source. What you do is wrap Linux in wires and place him in a magnetic casket. Putting C++ in the kernel will cause him to roll fast enough to generate enough electricity to power North America.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>