Slashdot Mirror
Object Oriented Linux Kernel With C++ Driver Support
An anonymous reader writes: An effort underway called BOSS-MOOL, the Minimalistic Object Oriented Linux, is designing the Linux kernel with OOP and C++ driver support. Linus Torvalds' opinions on C++ have long been known while developers at the DOS Lab IIT Madras and CDAC Chennai feel redesigning the kernel with object oriented abstractions and C++ driver support will increase maintainability while reducing complexity of the kernel. It doesn't appear though the group will try to mainline these changes.
BeOS used C++. Microsoft Windows uses C++ -- albeit with the CRT (C Run Time) library separated.
Linus hates C++ for kernel development because C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling. The C++ committee would rather add a 2D graphics API that no one cares about to the language libs then focus on binary compatibility.
It's more popular than Turbo C.
You're making that up. Linus's actual arguments against C++ for kernel is mainy rhetoric about "substandard programmers". The real issue is that Linus has no real experience with C++, therefore does not deeply understand its organizational advantages. Speaking as a longtime C hacker who did make the effort to figure out what C++ is all about. It's true, C++ is far from perfect, but on the whole it beats the crap out of good ole C along multiple dimensions.
When all you have is a hammer, every problem starts to look like a thumb.
C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
I *do* like the ability to free up resources in a c++ destructor, but as he points out, that's not something you want to rely on in system software. The c++ committee has java envy.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
For a short while, the Linux kernel could be compiled as C++. Some developers, I believe Linus included, felt that the stricter type checking offered by C++ would help kernel development. There was no attempt to actually use C++ features though.
The effort did not last long.
Finally! A year of moderation! Ready for 2019?
There is (or rather i should say there's been a lot of progress towards) a standard C++ ABI. G++ has been following it since 3..0 days, and it really got stable around 3.4.
It's a bit off to be angry at the name mangling Name mangling incompatibility is actually a feature. It's purposely different to make things not link up because the real things (static function initialization, object layout, including virtual table layout, etc) are incompatible. Be angry that those things aren't standardized, or not enough.
well, that's pretty a rather sweeping statement which would incur a lot of context switching just to make you happier.
I got the impression that C was faster and less prone to quirky, inscrutable API's than C
I always knew that there's something strange with C. It's faster than itself!
The Windows kernel APIs are all C, there is no C++ in it. You can use a subset of C++ that doesn't require runtime support, but it is unsupported.
Linus hates C++ for a lot more reasons than ABI, and the majority of them are completely uninformed and show a lack of C++ experience.
All the understandability and maintainability worries people have about C++ in the kernel would be easily controlled by standard patch review. Don't like giant template metaprograms? Don't accept the pull request. That easy. Perhaps one of the valid reasons to keep C++ out of the kernel right now is purely that Linus would be unable to review such patches with authority.
Even simple things like classes, RAII, basic templates, and exceptions would do wonders for development.
I'd argue, that the primary usefulness of C++ is for large developer-groups, where at least some programmers have vastly lower experience. It helps compartmentalize various things and hide internals. This is not all that useful, when the software project at hand is an operating system kernel — newbies should not be messing with that to begin with.
The other benefit of C++ — stricter compiler, which will flag various problems at compile time — is rather marginal, because commonly used C-compilers (clang, gcc) can be (and are) asked to do the same flagging as well. For example, here are the warning-flags used by my FreeBSD system to build its kernel: -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs...
In Soviet Washington the swamp drains you.
In a world with only C and C++, then C++ is undoubtedly the better language on balance.
I would still pick C, and use it to write a higher level language compiler / interpreter.
C++ can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling
IIRC from Stroustrup, non-standardized name mangling is considered a feature because it acts as a public interface for many other non-standardized incompatibilities under the hood. Without it, it would be possible to link code emitted from different C++ compilers that would fail to interoperate properly in subtle and difficult-to-debug ways.
So it isn't quite fair to imply that if only name mangling were standardized the problem would go away: it would really require a very large enhancement to the standard that would deal with all the different ways that compilers do things now. That potentially involves a vast amount of work on understanding current compiler technology, much of which would likely be obsolete by the time the standard shipped. Ergo: compiler compatibility is unlikely to ever happen.
I'm not saying this is a good thing, just that it's a thing. I currently code in C, C++ and Python, and C++ is by far the most difficult, dangerous and awkward of the three (or of any language I've ever coded in, really) but the additional power does make it worthwhile in certain circumstances.
Blasphemy is a human right. Blasphemophobia kills.
No, he hasn't bothered, which I understand. He's got a lot of work to do and a lot of people around him who are telling him that his approach is the right one. That doesn't mean it is.
Mad Software: Rantings on Developing So
Back in the 1990s I worked on a large ATM networking driver written in C++ for OS/2. The driver was around 100,000 lines of code. It was quite fast and reliable code and fairly easy to work on. We also had a driver for Windows NT written in C. The C driver had fewer features and was a lot buggier, slower and was 360,000 lines of code. It was also harder to work on since C++ provided a lot of nice abstraction.
Now the C++ code only used a subset of C++ and it kept the data path fairly flat to help optimize speed. The actual overhead from using C++ vs C was fairly minimal as well.
The ATM driver was quite complex since it supported the full signalling stack and switched virtual circuits and ATM LAN emulation for both Ethernet and tokenring and classical IP over ATM using switched circuits.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Can anyone really argue with this:
Yes, mostly because it's crap filled with logical fallacies and a staggering ignorance of C++. I would respond, but someone already did it better:
http://ridosandiatmanto.wordpr...
I *do* like the ability to free up resources in a c++ destructor, but as he points out, that's not something you want to rely on in system software.
Don't see why not. Would you ever want to forget to unlock a mutex? Why not let the compiler guarantee correctness rather than have to do it by hand every time.
SJW n. One who posts facts.
Virtually all kernel functions return either NULL, true/false, or -errno for errors. No need nor desire for exceptions.
Just how would you do an exception inside an ISR, if you could even find a [credible/safe] way to implement them inside a kernel?
Uncaught exception === kernel panic?
Like a good neighbor, fsck is there
I would still pick C, and use it to write a higher level language compiler / interpreter.
All the major C compilers which offer any kind of useful optimizations are written in C++. So you'd still be making heavy use of C++ under there.
SJW n. One who posts facts.
You should not free up resources in a c++ destructor. I guess that is exactly what Linus meant with his quote.
http://c2.com/cgi/wiki?BewareO...
http://www.codingstandard.com/...
C++ destructors can be used to deallocate any memory, or do other stuff that cannot go wrong. But they cannot be used to release any resources, like sockets, streams, files, connections, etc.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
If you want to know why C++ sucks for operating systems design, look at COM.
And if you you want to see why C sucks for operating systems, look at Windows ME.
Your point?
SJW n. One who posts facts.
C++ is an enormously powerful and comprehensive language, and it relies on the programmer or organization to use a reasonable subset of it and use good judgement in applying any given feature. I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C. More critically, C++ interfaces and methods can be written in such a manner as to provide much better protection to the programmer from his own mistakes. It's much harder to do that in C. In today's security-conscious world, where a single mistake can mean a critical OS vunerability, that's a real issue.
Essentially, C++ is C plus the ability to create powerful abstractions, typically expressed in objects/classes and templates, but not necessarily limited to those. Those abstractions put more of a burden on the compiler rather than the programmer, and as a result, is much safer than anything one could write by hand. All raw memory buffer manipulation, for instance, can be done through carefully protected wrapper objects or other user-defined primitives, and there's no reason in modern C++ to manipulate object lifetime through raw pointers, as it now has standardized smart pointers. Any resource - memory, file, locks, handle, etc, should be lifetime managed by objects - and so modern C++ should feel a lot like a garbage-collected language. In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management (e.g. IDisposable in C#).
It's certainly not a language suitable for all tasks, and it arguably requires more expertise than C to use it well. However, systems programming is absolutely one of those things it's well suited for. Binary compatibility would be great to have, but is not a real hurdle. To work around it, you can simply fall back to a C-like API at module boundaries, and avoid passing any objects across. That's what I typically do when I have to write C# C++ interop layers, and it's worked pretty well for me. While it brings along a lot of cruft, C compatibility, including it's binary compatibility, is one of C++'s great strengths as a language.
Irony: Agile development has too much intertia to be abandoned now.
One of the real powerful things about C, especially for writing an operating system, is that a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated. In the presence of C++ inline functions, implicit type converters, copy constructors, and assignment operator overloads that ability goes right out the window. If you were managing a project that involved lots of small contributions from a large and widely distributed group of developers that inability to see what a small patch does would be fatal.
On a more subtle level, C++ rewards a well-thought out design that doesn't change very much, and mercilessly punishes a design that is produced incrementally in an evolutionary fashion. Given how Linux has developed over the years, C++ would have been a brutally punishing language for Linux.
I like C++, I've used C++ in quite a few projects. I will probably use C++ again. But I can easily see why the Linux kernel is not a great place to use C++.
I cannot see how introducing something like C++ will improve the situation. Changing the langauge doesn't get rid of evolutionary code, nor does it fix people's thinking. I can't fault the guys who evolved the musb driver into a working piece of code - the crux of the problems originate with the original Mentor documentation: Unavailable, poorly coverage of errata, poor detail on what the hardware block is doing.
What is required for good drivers are:
If hardware vendors wish to compete for embedded linux systems, then they should promote their performance on how well they do on the open test suite with their linux drivers - not just on their arm core's performance.
-bms
Uncaught exception === kernel panic?
That's one way to force device driver writers to get their shit in order...
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Correction:
, is that a good C programmer can look at a piece of well written C code and have a pretty good idea of the machine code
I've had to maintain some real winners of C code where the programmer went hog-wild with macros. UGH. It was easier to rewrite everything than to understand what was being done.
I think we've pushed this "anyone can grow up to be president" thing too far.
I'm sure everyone will believe your theory that linus just can't grasp C++'s advantages and that's the reason why he doesn't want to rewrite the entire kernel in C++
C++ object can be linked with C code, I have used that ability to add C++ code incrementally to projects originally developed in C. As a result, have had plenty of opportunity to compare the C++ result to the original C. Typically, equivalent or identical object code but source is more consise, readable and maintainable.
When all you have is a hammer, every problem starts to look like a thumb.
So what would you do in Java with destructors?
There's more resources than just memory. Files, sockets, database handles, mutexes, unlocking mutexes and so on and so forth.
SJW n. One who posts facts.
The name's just factually incorrect . What they really should have named it is ++C.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
The Linux kernel makes heavy use of big ugly, hard to maintain or read macros that generate arbitrary machine code. No matter how good you are, you won't know what code is being generated without extensive analysis. In any case, the exact same ugly macros can be used by C++, if you are really wedded to that kind of bad taste. C in fact has no addtional features in this area, it only lacks features that C++ has.
If you want to point at features that C has which C++ does not then you get a very small set, which in the case of the kernel consists mostly of designated initializers.
When all you have is a hammer, every problem starts to look like a thumb.
In fact, I'd say it's superior to a garbage collected language in many respects, because garbage collection is not nearly as predictable as object scope rules, and doesn't extend quite as nicely to non-memory resource management
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion. In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz. In Java, even with the better garbage collector designed for servers, "bouncing off the roof" is the norm, and it's quite hard to tell when danger is approaching.
I'd be interested in any /.er advice here - is there some dependable way with Oracle Java to measure "real heap size" - the total size of objects actually in use? The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.
Socialism: a lie told by totalitarians and believed by fools.
Every sufficiently large C project re-invents key portions of C++, poorly. I've been involved with a couple such efforts myself. There's just no excuse for the NIH-ism. The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Socialism: a lie told by totalitarians and believed by fools.
With the limitation that C++ destructors cannot throw exceptions, why would you need them in Java?
To explicitly reclaim the memory immediate on a small memory footprint requirement environment, instead of waiting until "the GC fucking feels like it, at the worst possible time", which is when I need more memory for something else.
It's one of the reasons I dislike some of the Objective C changes to use autorelease pools as well. Any language which requires GC'ing to reclaim unused memory is totally unsuitable for small memory footprint applications.
Like gcc, oh wait, not that is written in plain and simple c.
You misspelled "was". The compiler was switched over to C++ a few versions ago and they're now using C++ features.
SJW n. One who posts facts.
And I wouldn't say that C++ adds much to maintainability -
Actually, it does, by giving you abstractions instead of you having to write them yourself as you do in C. In the embedded world, there's a term: "C with classes": this is when C++ is used on embedded systems, but only a small subset of C++. The code looks pretty much just like C, but there's classes and inheritance, but many other things are specifically omitted, such as exceptions. In aviation (DO-178), there's standards for using C++ in avionics systems, and here again, they specifically forbid the use of many C++ features which prevent determinism, such as exceptions.
If anyone's going to write a kernel in C++, they should just follow the FAA DO-178 standards.
Worse, his counter-example is broken, since most if the code is missing - even when you look at the page in source view.
And I've seen c++ programmers make the same mistake about putting strlen() in a conditional test. More efficient code wouldn't use either strlen() or a for() loop, but take advantage of the fact that strings in c are null-terminated.
As for the ending:
The fact is: Look at almost any complicated data structure made in C, and it will almost invariably be a horrible mess which is very error-prone and extremely hard to understand and maintain.
I’m not saying that many such data containers made in C++ aren’t a mess. However, C++ at least offers you the tools to make it cleaner. C doesn’t offer you anything (after all, it’s a “sparse” and “straightforward” language) and thus C constructs tend to look like a huge mess.
Have you looked at the mess that is the string class in the stl? Even that is fugly. When I use c++, I write my own classes, not because I can, but because I want code that I know will behave the way I expect it to. The extra time to hack together a minimal string class and debug it is more than paid back when trying to figure out where something is going wrong. And that goes for pretty much any container class. If you can't write your own basic c++ containers, how the heck can you be expected to design (or even understand) something more complex?
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Because the compiler cannot guarantee correctness. That you think so is what make C++ and C++ developers so dangerous, especially in kernel space.
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Is C++ going to solve RCU and complex atomicity issues? Is C++ going to make run-time dynamic code generation easier? (That is, replacing NOP instructions at boot time for optimization and debugging.) No. In fact, C++ is worse for these things because C++ does too much implicitly, which makes it harder to reason about the code.
Before you opine on why C++ is better, why don't you download the C++11 and C11 specifications and read them thoroughly. Then contemplate how you'd write implementations for those. Then reassess how much, exactly, C++ simplifies anything.
Too many developers believe that as long as you _hide_ complexity, it has no cost. If it doesn't look complex on its face, how could it possibly hurt? Or by ignoring a feature you think it's magically disappeared. That's wrong on so many levels that it's difficult to even have a rational conversation with people who think that way.
If you're going to OO the kernel -- skip C++, and make it Java. At least you get the type checking, which I'm sure today's kernel devs will hate to the 9's, but could be a huge benefit in cross compatibility AND consistency w/o building gigantic teams to maintain it--I'm looking at you ARM implementations. You all may laugh at that idea, but LLVM is basically the same idea.
And all those resources are closed just fine by Classes that implement the Closable interface and objects that are used in a
try (object)
statement. ... sigh!
You Java knowledge is 5 to 10 years behind modern Java
And for fuck sake, Java has build in support for multithreading, a mutex is not acquired by a constructor nor is it released by a destructor, for that we have a keyword: synchronized. Since Java 0.7 I believe.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
To be fair: So is C.
Who ordered that?
With C you just need to follow the code without worrying about a constructor being called or an operator being overloaded.
Until your compiler starts optimizing things.
Or anyone mentions "#define".
Or you have to worry about concurrency.
Or interrupts.
Or memory-mapped I/O.
The claim that C++ does lots of magic but C does not is one of those mythical ideas that makes us feel better about deciding to use C for some systems programming job, but really there's plenty of magic that goes on in both. If you're working on things like operating systems or device drivers, you simply have to know how your code is going to compile in all kinds of situations. Next to that, the differences where C++ systematically provides for things like construction/destruction or overloading are relatively minor concerns.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I've had to maintain some real winners of C code where the programmer went hog-wild with macros. UGH.
I sympathise, my first experience writing commercial code in C++ was in the early 90's with the Watcom compiler of the day. Their implementation of C++ was not part of the language, it was a complex layer of C macros that served as wrappers for goto statements, function pointers, etc. I had learnt about OO concepts from smalltalk a couple of years earlier while studying for my degree, the Watcom macros were what I'd call a "sociopathic implementation" of some of those ideas.
The mistake Watcom made back then is the same one many developers are still making today - "object orientated" is not a language feature, a layer of macros, or a bunch of library calls, it's a powerful and ubiquitous design methodology.
For example, if you look carefully at the examples in K&R's "C programming language", most are excellent demonstrations of OO design that were written long before the term "OO" was invented. The elegance that many developer's perceive in K&R's famous examples is not in the syntax, it's in their design.
Next up - "Spaghetti code" is not a language feature.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
It's not about what Linus wants, it's about what it takes to keep project relevant by attracting talented new developers. There is no way I am doing new work, especially an unpaid hobby project, using plain C in 2014. Automatic destructors and templates would be a step in the right direction, but what we really need is to be able to write user mode device drivers in Java and Python. They will suck, no doubt, but far less than not being able to use the hardware at all. In the end, perhaps Linus should have listened more to Andrew Tanenbaum. With less monolithic OS, people would be able to write key services in any language they want.
Considering that most new phones are being released at 2 GB+ configurations, I care less and less about 'small embedded systems that are becoming more and more niche and obscure'.
Being able to write an efficient program will never become an obsolete skill. If you are using excessive memory, that means your program is wasting CPU cycles. It means you are running my battery down and making me wait for your bloated program to load.
I recently had to rewrite a modestly sized embedded project from C++ to C because it became clear that I could not afford the space for the mandatory libraries in the binary.
I did so by retaining the organizational concepts imposed by methods but made the implied "this" pointers explicit. I had to reorganize to undo the damage done by losing inheritance, virtual functions, etc. In a way, my biggest loss was losing overloading and templates. Those afforded elegant solutions that C doesn't match.
When I was done my source code actually shrank and my output binary size was cut in half. In no way could anyone argue that the code became less maintainable or less readable. Execution was notably faster and there was none of the god-awful unknown code executing that I had no control of. Exception handling is gone as is RTTI. Good riddance. I love some things in C++ but, on the whole, it is very burdensome.
Java has JMX which can be used to do this much better than C++ can ( at least without a ton of effort ).
With Java you get this all out of the box. You can point a JMX console to your Java Runtime and monitor with zero code. Or use java.lang.management package programmatically.
It seems you missed my point. Both C and C++ have huge amounts of non-obvious things going on under the surface with modern compilers and processors/hardware architecture. The parts of C++ that add further implicit behaviours really aren't that big a deal in comparison, and ruling out C++ for systems programming on the grounds of magic happening and expecting C to be much better in that respect is highly optimistic.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Tracking the frequency/duration of full collections is the usual approach. The GC has to work harder as heap space runs out, a system which is tight will do frequent full GCs vs one which is running with plenty of head room. In particular if you're using G1, seeing full (single thread) GCs at all is a bad sign. I'd also do this out of process, either by monitoring via JMX or simply scanning GC logs. A process trying to monitor itself rarely works out well :)
The better garbage collector for servers (G1) never pauses the world to free everything it can, so it's not like you can look at post-collection heap size or anything.
It's an over simplification to call G1 "the better collector for servers", it's more complicated than that - and G1 certainly can do a stop the world, it just tries to avoid it.
I'd also say this - if you're capable of writing C++ without any resource leaks you're capable of writing Java without any resource leaks. In which case memory usage will be predictable and simple load testing will show you how big a heap you need to allocate.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
But you do know that "small memory" VM try to reclaim memory during the 'new' or 'alloc' call and don't have a GC which is waiting till 'all memory is consumed'? ... you have no clue. Sigh, 30 years of computer science wasted in stupid IBM vs MS vs Sun vs Apple vs Oracle wars. ... (yes, that adds up to 40 years, your turn?) /. claim of a 25 year old and say: wrong!
Guessed so
I guess I mentioned often enough that our days computing experience is minimum 20 years behind what *I* learned at my university 20 years ago
You can basically pick a random
I worked on SVR3 (kernel), SVR4 (kernel), AIX (kernel), FreeBSD (kernel), iOS (kernel). I also worked on ChromeOS/Linux (kernel).
The reason you wait to reclaim memory, rather than doing it on a stupid timer, is that you can't put the CPU into standby mode for much longer times to conserve the battery and thereby extend battery life.
If you reclaim memory explicitly, that's OK, since it means that you're already running, and that won't screw your battery life.
Guess why Windows on a MacBook doesn't have as long a battery life as Mac OS X on the same MacBook? Because Windows *polls* its USB devices, because it can't be sure that the internal USB controller isn't shit, and because it can't know, even if the internal USB controller isn't shit, that the internal devices like the keyboard and trackpad connected via the Qualcomm microcontroller aren't shit, because it doesn't make a distinction between the internal and external USB controllers. It fails here because it has to run on all the crappy hardware that's out there, because it's an off-the-shelf copy that can't make hardware assumptions.
You can basically pick an old fart (who learned before systems incorporated substantial power management technology) or for that matter, a young kid who thinks all computers are Linux boxes plugged into the wall, and then pick any /. claim they make that doesn't take power management into account and say: wrong!
The importance of this is underestimated. With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.
Unfortunately, you can't use any of that in the kernel [overloading create/destroy new/delete operators won't cut it]. Spinlocks, rwlocks, RCU, slab allocation, per cpu variables, explicit cache flush, memory fence operations, I/O device mappings, ISRs, tasklets, kmalloc vs vmalloc, deadlocks, livelocks, etc. are the issues a kernel programmer has to deal with. Nothing in C++ will help with these and some C++ constructs are actually a hindrance rather than a help.
For instance, copy constructors must be disabled. This was part of a proposal a few years back to make a C++ subset suitable for realtime/embedded. It isn't acceptable to have "x = y" invoke an unexpected amount of code simply because you inadvertantly invoked a copy constructor.
Kernels by their nature are messy. Anybody writing kernel code must be fully aware of the implications of doing something and must be aware of the state they're being called in. Abstraction just makes this job harder not easier.
For example, all kernel code must be compiled with -mno-red-zone because of the threat that any base code could receive an interrupt at any time [even between 2-3 machine instructions that comprise the red zone setup code].
Linux already does a pretty fair job of keeping things clean. If you don't believe that, actually go read the kernel source code. And, if something ends up being crufty, it gets cleaned up. Even if that means that some 100 or so modules need corresponding changes.
Like a good neighbor, fsck is there
The only thing C++ solves in kernel development are problems that nobody cares about. Replacing macros with templates and long function names with namespaces buys the kernel developers precisely nothing.
Replacing macros with templates and long functions names aren't exactly the killer benefits most people think about for C++. It's typically things like avoiding memory corruption and resource leaks, which can both be really bad in an OS kernel. Even so, I'd argue that they DO buy kernel developers something. Macros are completely type unsafe, and can silently generate bugs. More sanely named overloaded functions and namespaces help to make code more readable. Are kernel developers somehow magically exempt from features the rest of the world finds useful?
Still, even as a C++ advocate, I would never really argue that C++ solves all problems, is easier to use, has no hidden costs, or even is the correct language to use in all situations. Good C++ programmers understand the costs of features they are using and the tradeoffs they're making. There are bad programmers in every language, including C++. Personally, I'll probably always choose C++ for my own projects that require high-performance native code because it provides some very significant benefits:
1) Using class based abstractions can virtually eliminate some really dangerous categories of bugs like buffer overruns.
2) It's almost impossible to leak memory or resources with properly designed wrapper/interface classes.
3) Well written C++ interfaces can make it harder to misuse APIs in general
4) These benefits are typically provided at either zero or with minimal overhead. There is no "hidden" overhead if you understand how the language feature or library works.
5) For times that this overhead is critical, you can revert back to C. For all other cases, you can prefer the higher-level abstractions and the safety and convenience they provide.
Generally speaking, I'd say it's harder to write good C++ code and design great C++ interfaces. However, once those interfaces are created, they tend to be far easier and safer to use - even for the person who originally wrote them. Most of my own library classes are designed in such a way that I couldn't cause crashes, leaks, or memory corruptions with them unless I tried really hard to do so using blatantly unsafe techniques (which C++ lets you do, of course, just like with C).
If I had to sum up, the significant benefit of C++ is that it makes it possible to protect the programmer from making mistakes to a much greater degree than in C while retaining most of the performance benefits of C. We've seen it demonstrated quite clearly, time after time after time... programmers are only human, and will always make silly mistakes. Why not take advantage of the language and compiler to help minimize the chances of making those mistakes in the first place? To me, that's the essence of C++.
Irony: Agile development has too much intertia to be abandoned now.
Having been on the fence about this for a while, my experiences convinced me that C++ is wrong for the kernel.
The problem is not the extra features. The problem is that the programmer has little control over exactly how they are implemented: the compiler decides how to handle virtual method tables, destructors, multiple inheritence, etc. In the recent past, C compiler bugs have caused serious problems with Linux development. C++ compilation is an order of magnitude more complex, and you can bet it would be less reliable. This also means that C++ compiles much slower: doesn't sound like a big deal, but it is a cost to take into account.
The lack of a standard, clear ABI for C++ is also problematic. While it's true that Linux is monolithic, it still supports modules that interact with each other dynamically. Debugging C++ can be quite painful because of this. But it also means that it would be that much harder to contribute a module if it's not written exactly for the same compiler as the one used to build the kernel. Of course, it would have to be written in C++, too. This lack of flexibility can be quite painful in environments where you are limited to very specialized compilers (embedded). C has the most standard ABI of any language (well, C and Pascal). You can guarantee that *anything* would be able to interface with it.
So if you put the technical cons (losing control, flexibility and debugabbility) vs. the pros (cleaner syntax) then it's right to pick C, on technical grounds. As others have stated here, anything you can do in C++ you can do in plain C. It's a bit clumsier, but then you have complete control over the implementation. I do OOP in C all the time, it's perfectly OK. If anything, a bit more powerful than C++, because I tailor the OOP features to exactly my needs and tastes.
Beyond that, there is the more controversial issue of programmer culture. C++ hides away implementation details, but for kernel development you want programmers who think about every tiny issue of implementation: exactly what is going on with the call stack, what is a pointer and what isn't? The more explicit nature of C encourages a more hard-nosed stickler for technical correctness, which is more important than pretty code for kernel work.
By the way, I'm writing this as a former C++ zealot. I even created something like this in the past, a C++ wrapper for Windows NT networking services. I found out the hard way that C++ takes more than it gives. I write all my code in C these days, and don't feel like I'm missing anything.
The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Unfortunately, C++ includes an explicit non-standard that can inject subtle bugs. This has been present since at least 1988, and has survived at least the first two standards (after which I stopped watching, having moved on to mostly hardware design).
(I DID try to bring it to the attention of the standards committee in both cycles, but it was ignored. Bjarne, in his recent Slashdot Q&A, didn't answer my question on it, either.)
The problem relates to which overriding of a virtual function is called during the initialization of the member variables and the construction of member objects of a derived class (and the corresponding destruction of the member objects during the destructor). The standard permits the calling of the derived class' version of virtual member functions at this time, when the derived class has not initialized, or has dismantled, their underpinning.
Compilers are permitted to cause the call to go to either the base class version (IMHO correct) or the derived class version (IMHO dangerously incorrect). Calling the derived class version is bad, preventing a number of obvious constructions from working as expected, imposing limits on what programming techniques can be used safely, and displaying no warning (so the programmer has to know what not to do). Letting different compilers make different choices is horribly worse, as it makes the behavior unpredictable and compiler dependent.
C++ (especially the early versions, before it became buried in libraries and baroque constructions) came SO close to being a powerful and reliable tool for rapidly writing reliable code on large projects. But this "little bug" brought it all crashing down.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
If you don't think Linus has enough C++ experience, how about the man who created of C++ as a hoax, Bjarne Stroustrup:
Interviewer: If we publish this, you’ll probably get lynched, you do realise that?
Stroustrup: I doubt it. As I said, C++ is way past its peak now, and no company in its right mind would start a C++ project without a pilot trial. That should convince them that it’s the road to disaster. If not, they deserve all they get.. You know, I tried to convince Dennis Ritchie to rewrite Unix in C++..
Interviewer: Oh my God. What did he say?
Stroustrup: Well, luckily, he has a good sense of humor. I think both he and Brian figured out what I was doing, in the early days, but never let on. He said he’d help me write a C++ version of DOS, if I was interested..
Interviewer: Were you?
Stroustrup: Actually, I did write DOS in C++, I’ll give you a demo when we’re through. I have it running on a Sparc 20 in the computer room. Goes like a rocket on 4 CPU’s, and only takes up 70 megs of disk..
Interviewer: What’s it like on a PC?
Stroustrup: Now you’re kidding. Haven’t you ever seen Windows ‘95? I think of that as my biggest success. Nearly blew the game before I was ready, though..
Interviewer: You know, that idea of a Unix++ has really got me thinking. Somewhere out there, there’s a guy going to try it..
Stroustrup: Not after they read this interview..
Obviously the BOSS-MULL developers never did read it. You can here.
The fact that *EVERY* line of kernel code has to deal with those kind of issues is a byproduct of the monolithic kernel design, not what the code itself is doing.
I started off as a Unix kernel programmer in the late-80's, did a lot of stuff on supercomputers and went to Apple to work on Copland (micro-kernel). I/O subsystems can make good use of OO abstractions. OS X's IO subsystem is written in C++.
It's really time to look at microkernels again. There are some performance issues, but many of those will get smoothed out as they're hit and engineered around.
The argument around gets as an example of how c leads to bad design is bogus. Even the man pages point out the problem.
So? GCC ended up actually building in some optimizations to make that poor example run fast because despite the man page, people write it in code so much it was worth hacking the optimizer. The point is not that C++ is faster than C, it's that the obvious choice in C++ is often much faster and cleaner than the obvious choice in C.
Have you looked at the mess that is the string class in the stl?
It's a mess in that it has a bunch of functions plus the kitchen sink included. But it's still not hard to understand because the encapsulation works well. Also, just because the C++ standard ossified one bad design choice from 20 years ago does not mean that C++ is worse than C. I could find heaps of terrible C code for you if you like.
And that goes for pretty much any container class.
Oh god I've had to work with people like you. I worked with as guy who believed like you and hacked together his own vector class. Well, he mad a bunch of mistakes. He forgot exponential growth, so algorithms were asymptotically worse (and slower in practice) using his class instead of vector. He also forgot to not use const references in things like push_back() because that will ocasionally break if you do vec.push_back(vec[0]). And so on.
The STL is extremely well specified. Anyone capable of reading cplusplus.com can see exactly how any vector implementation on any implementation outhr to work (modulo bugs, though I've never encountered a STL bug in the wild).
If you spent half the time perusing the spec than you spent duplicating the STL, you would not find the behaviour "unexpected", you'd save time and other people would find it easier to follow your code.
SJW n. One who posts facts.
To work around it, you can simply fall back to a C-like API at module boundaries
And thus losing the entire reason for using C++ in the first place. The whole point of this project seems to be that they want drivers as C++ classes. If you do that then you end up with a giant mess of wrapper functions to translate calls from simple C to C++ object calls.
Actually no. All you need is one C function to pass the driver class instance to whatever wants to use the driver. From there on you can use the instance to make the calls directly in a C++ manner.
To implement the exception handling logic in assembly requires flow control outside of the inline asm block, which is not legal in GNU C (and inline asm is not part of standard C). For zero-cost exception handling to work, you must emit unwind tables that contain information about the locations (on the stack or in registers) of every local variable at each call site. You also make every call a branching (local) flow control construct, which changes the valid compiler transforms you can do. You can, in theory, do this in GNU C by making your entire function an inline asm block that takes the function arguments as input parameters (ooops, might run out of registers if any need to be passed on the stack), but you'll then have to be as good as the compiler at optimising because the optimisers won't touch your code.
I am TheRaven on Soylent News
I would grant that poorly written C++ is probably much worse to detangle than poorly written C. However, well written C++ is just as usable and maintainable as well written C.
And which do you think you are more likely to run into? And which do you think is more likely to be contributed to your project?
I'm a minority race. Save your vitriol for white people.
You don't realize that "interview" is a parody??? Nor do any of the people modding up your post as insightful???
Idiots. (Or jokers, which I guess would be OK, but sheesh, that's what +1 funny is for...)
You are correct on the last, but not the preceeding items. I had the opportunity to talk about it with Carl J. Sasserath himself. IIRC, he was actually inspired by Smalltak, but don't take that as immutable truth.
The Amiga's OS consisted of several layers. The Exec, AmigaDOS, and the GUI, which internally subdivided into the layer and window systems. Everything was very modular.
AmigaDOS was indeed written in the "British Cruddy Programming Langue" based on a thesis project named Tripos. However, it was jammed on top of Exec, which was written in C. The results were occasionally awkward, as BCPL used word-based addressing and C was byte-based. Plus the BCPL and C stacks grew in opposite directions.
The C compiler used was Green Hills C, cross-compiling off Sun or Apollo Unix machines (again, memory is hazy here). Manx was the first C compiler native for the Amiga, followed by Lattice C. Manx was probably a Macintosh port, as it worked with 16 bit integers. Lattice worked with 32-bit integers, which was a more natural fit for the machine. Eventually, the 2 compilers adopted support for each other's word sizes and all became happy (more or less). By that point, Commodore was doing native development and no longer needed to cross-compile.
The Amiga OS source code had no embedded assembler that I'm aware of. Embedded assembler is a hallmark of complex monilithic systems. Exec was very minimalistic and so far as I am aware, the assembler components (primarily scheduler and interrupt services) were all separate source modules. The C compilers did add pragma directives to allow passing parameters in registers instead or (or in addition to) on the stack, support for volatile variables (for memory-mapped I/O devices) and similar.
C++ first began to get public notice about August 1986, which is when Amiga computers began to hit the street in quantity. But despite not being written in C++, Amiga's Exec mapped very well to it.
Check out the Wikipedia entry for Carl Sassenrath. I believe it has a link to a BYTE magazine article that discusses this.
An interesting thing about the Amiga's OS was that you could run a workhorse machine with GUI in 6MB of RAM. The equivalent port of Linux to the Amiga required 16MB. However, the Amiga's OS didn't support virtual memory, as the earlier Motorola 68000-series processors didn't have an MMU.
Actually, I do have to retract my statement about DO-178 standards: using these standards as-is wouldn't work for general-purpose computing kernels, and one giant reason is that DO-178 doesn't allow you to deallocate memory. Once it's allocated, that's it, it stays allocated forever. So "free" (C) and "delete" (C++) are forbidden. This would make your PC run out of memory pretty quickly. It's done in embedded systems because it provides deterministic behavior, and such embedded systems only do one task (or a small group of tasks), continuously, and unlike, say, a smartphone, aren't repurposed to do other things that use a lot of memory (such as running the Firefox mobile browser, then switching over to the Facebook app, then running Tinder, then playing Angry Birds, etc. There's not enough memory in a phone for all of that staying allocated at once.).
Anyway, perhaps a subset of the standards could be used, such as forbidding C++ exceptions. A lot of places I've seen do stuff like this: they use C++, but with a lot of specific rules on which features are and aren't allowed, and exceptions are a big one on the forbidden list. Basically, the main idea is places doing this kind of development like some of the C++ features like object-orientation and inheritance because it lets them avoid doing some of the nasty stuff you see in the Linux kernel, such as all the callbacks and tables used for mapping function pointers; with C++, you can just do that stuff using the standard OO features. Also, templated code: there's a huge pile of #define macros in the kernel which are really just implementing template code, which could easily be done with C++ templates instead. Shifting to C++ would allow eliminating many lines of code this way, and probably making some things safer (not having to worry that you're checking every function pointer for not-null before calling it, for instance), and theoretically this shouldn't affect performance if the compiler works correctly as the generated object code should be the same. It would be an interesting project to rewrite parts of the kernel in C++ and then compare, line-by-line, the object code and verify it's mostly the same and that performance isn't affected, and if it is, fix the compiler or at least identify specifically why it isn't the same.
placement new doesn't work without nullifying a few things. Automatic cleanup on scope exit doesn't work for locks in the kernel. See below ... Much more ...
placement new/delete are noexcept functions. But, they call std::terminate--not acceptable. The only thing that works is an alloc function that returns NULL (or (void *) -errno). Returning null is not fatal in the kernel. The caller must be able to deal with it (usually returning -ENOMEM). So, the [global] new/delete must be changed. Also, placement delete has problems [I've left off the backslashes for clarity]:
#define GETPTR(_ptr,_typ,_siz) // ...
switch (_typ) {
case 0:
_ptr = alloca(_siz);
break;
case 1:
_ptr = kmalloc(GFP_KERNEL,_siz);
break;
case 2:
_ptr = kmalloc(GFP_ATOMIC,_siz);
break;
case 3:
_ptr = slab_one(_siz);
break;
case 4:
_ptr = slab_two(_siz);
break;
}
void
myfnc(int typ)
{
void *ptr;
GETPTR(ptr,typ,23);
class abc *x = new(ptr) abc(19,37);
}
At this point, a delete operator [even a placement version] has no idea which pool to release to because there's no way to pass typ to it. You might be able to create a contructor abc(typ,19,37) but that adds an extra member element to hold typ so the delete operator can get at it, but that's additional overhead/complexity that C doesn't have. It might be possible to make it work by casting typ to void* and using that as the pointer:
class abc *x = new((void *) typ) abc(19,37);
and have the class specific new operator use GETPTR internally. I tested this and it works. However, I haven't yet been able to get the corresponding placement delete to work as a class specific overload [yet]. In trying to find the way, I came upon:
http://www.scs.stanford.edu/~d...
It's fairly detailed and lays out a [pretty strong] case against using the new operator [more eloquently than I could do here].
A lot of kernel code puts definitions in the usual place [top of function body] for C. In C++, this invokes the constructor, which is not what you want. The reason is that [say] 10 vars are defined. The function does a quick check on args and does a non-standard return -EINVAL. All that wasted create/destroy. This may be harmful if the constructors have side effects such as lock acquisition. Note that doing a [wasteful] lock followed by an immediate unlock [to satisfy having a destructor do lock cleanup] is a non-starter in the kernel [you'll never get such code checked in/signed off on]
So, you'd have to go through every kernel function by hand [there are 16.9 million lines of source code] and move the definitions down: ... ...
{
struct foo x;
if (bad_news)
return -EINVAL;
}
{
if (bad_news)
return -EINVAL;
struct foo x;
}
You can't put a lock release in a destructor because you'd need an extra member var that would have to be set/cleared when you acquire/release a lock. That's because the destructor has to have some way of knowing whether to suppress the lock release. So, you're adding an extra variable [that isn't needed in C] just to prevent an attempt to release a lock that was never acquired in the first place. More overhead and slower [and more complex] than its C counterpart.
I
Like a good neighbor, fsck is there