Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Linux

Object Oriented Linux Kernel With C++ Driver Support 365

Posted by Soulskill from the redesigned-tux dept.
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.
This discussion has been archived. No new comments can be posted.

Object Oriented Linux Kernel With C++ Driver Support More

Object Oriented Linux Kernel With C++ Driver Support

Comments Filter:

  • Why do people still care about C++ for kernel dev? (Score:5, Insightful)

    by UnknownSoldier ( 67820 ) on Friday October 03, 2014 @02:55PM (#48058325)

    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 [open-std.org] that no one cares about to the language libs then focus on binary compatibility.

    • Re: (Score:3, Insightful)

      by Tough Love ( 215404 )

      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.

      • 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++.

        • Re: (Score:3)

          by HiThere ( 15173 )

          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.

          • "Object orientated" is not a language feature. (Score:4, Interesting)

            by TapeCutter ( 624760 ) on Friday October 03, 2014 @07:13PM (#48060115) Journal

            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.

        • Re:Why do people still care about C++ for kernel d (Score:4, Insightful)

          by Tough Love ( 215404 ) on Friday October 03, 2014 @04:15PM (#48058889)

          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.

        • Re: (Score:2)

          by lgw ( 121541 )

          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

          Do people not debug through object code any more? I've done that so many times when trying to understand a bit of cryptic C++ code or C macrology. There's no mystery possible - just look at the generated object directly if there's any doubt at all what's going on!

          • How is adding an extra debugging step better than just not needing it in the first place?

            • Re: (Score:2)

              by lgw ( 121541 )

              Unless the problem domain is quite simple, you need complex code to solve complex problems. And complex code always evolves into mysterious cruft, given sufficient time and coders involved.

              Sure, sure, some "code base" that one guy wrote in a few months? Very obvious and clear results are possible. But a real project with a few programmer-centuries of code? I've worked on assembly code where looking at the object was the only way to be sure of what it did (to see what the macros expanded into). And C is

      • Re:Why do people still care about C++ for kernel d (Score:5, Insightful)

        by Rennt ( 582550 ) on Saturday October 04, 2014 @03:21AM (#48061651)
        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 [cat-v.org].

        • Re: (Score:3)

          by sribe ( 304414 )

          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...)

    • Re: (Score:3, Informative)

      by BarbaraHudson ( 3785311 )
      Can anyone really argue with this:

      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.

      • That's what __attribute__((cleanup(function))) is for. Thank you, GNU C extensions!

      • Re: (Score:2)

        by suutar ( 1860506 )

        Heh. In my java programming I more often have C++ envy; I would _love_ to have real destructors. Most of my other gripes with C++ libraries are probably more a matter of familiarity than of real shortcomings. However, I cannot disagree with the point that for a kernel in particular, small/focused beats heck out of generalized libraries and behind-the-curtain operations.

        • Re: (Score:2)

          by devent ( 1627873 )

          With the limitation that C++ destructors cannot throw exceptions, why would you need them in Java? a close() method is just fine in Java, because you don't need to deallocate any memory. So what would you do in Java with destructors?

          • 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.

            • 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.
              You Java knowledge is 5 to 10 years behind modern Java ... sigh!

              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.

          • 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.

            • Re: (Score:2)

              by ADRA ( 37398 )

              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'. Sure memory optimization is good, but when resources are short GC's work harder and more often. If anything embedded systems are suited for GC language runtimes just fine, but they waste more CPU cyles for the privilage. The advantage with GC runtimes being that you don't get memory leaks (in the C sense of never being able to rec

              • 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.

          • Re: (Score:2)

            by suutar ( 1860506 )

            I'd have things automatically close()d when they leave scope instead of requiring the programmer to remember that this item needs a close(). The new automatic close feature in try blocks is close, but the project I'm working on isn't using that version of java yet.

        • Re: (Score:2)

          by HiThere ( 15173 )

          Java handles unicode much better than does C++. It also handles strings better. And synchronization between threads.

          N.B.: You *can* do all those things in C++, or even in C, but they're much nicer in Java.

          OTOH, I despise the UTF-16 coding used by Java. Enough so that I generally prefer Python or Ruby. though if I don't need specialized libraries my real choice is D (Digital Mars D). See http://dlang.org/index.html [dlang.org] .

          This, however, doesn't mean that I think Java, Python, Ruby, or D are appropriate languag

      • Re:Why do people still care about C++ for kernel d (Score:4, Insightful)

        by serviscope_minor ( 664417 ) on Friday October 03, 2014 @03:39PM (#48058661) Journal

        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... [wordpress.com]

        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.

        • The argument around gets as an example of how c leads to bad design is bogus. Even the man pages point out the problem.

          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

          • 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

        • Re:Why do people still care about C++ for kernel d (Score:5, Insightful)

          by Anonymous Coward on Friday October 03, 2014 @05:18PM (#48059323)

          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.

          • Re:Why do people still care about C++ for kernel d (Score:4, Insightful)

            by Dutch Gun ( 899105 ) on Friday October 03, 2014 @11:12PM (#48061091)

            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++.

      • Re:Why do people still care about C++ for kernel d (Score:4, Informative)

        by devent ( 1627873 ) on Friday October 03, 2014 @03:44PM (#48058705) Homepage

        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... [c2.com]
        http://www.codingstandard.com/... [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.

        • 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.

          More precisely, destructors can't be used to perform any operation which (a) may fail and (b) could be handled by the calling code (retry, communicate it to the user, attempt some thing else, etc.). If the calling code can't do anything about the failure anyway, then it really doesn't matter that the destructor has no good way to communicate it.

        • For most programs, the proper behavior on an error is to abort, then fix the program logic or repair the busted hardware. Assertions, etc ...

          As for why you'd want to allocate a new resource (the 3rd example in your first link) in a destructor, that's such an obvious no-no that I wouldn't even think of it in a million years. That is a very contrived example.

      • Re: (Score:2)

        by Yunzil ( 181064 )

        The c++ committee has java envy.

        Other way around.

    • can't guarantee a binary API from one compiler to the next due to shitty non-standardized name mangling

      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

    • Re: (Score:2, Interesting)

      by Beck_Neard ( 3612467 )

      If you want to know why C++ sucks for operating systems design, look at COM.

      • Re: (Score:2, Interesting)

        by RabidReindeer ( 2625839 )

        If you want to know why C++ sucks for operating systems design, look at COM.

        If you want to know why C++ is great for operating systems design, look at the Amiga Exec.

        Which actually was written in C, but mapped flawlessly onto C++.

        COM isn't object-oriented. You never actually had a handle on the object itself, just an interface.

      • 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?

    • Re: (Score:3, Insightful)

      by PhrostyMcByte ( 589271 )

      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

      • 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?

        • Re: (Score:3)

          by Thud457 ( 234763 )

          Uncaught exception === kernel panic?

          That's one way to force device driver writers to get their shit in order...

      • Re: (Score:2)

        by mysidia ( 191772 )

        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.

        Sounds like someone needs to send Linus some free C++ training <EG>

    • Re:Why do people still care about C++ for kernel d (Score:4, Insightful)

      by radtea ( 464814 ) on Friday October 03, 2014 @03:22PM (#48058549)

      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.

    • >>C++ can't guarantee a binary API from one > to the next

      Oh, you mean like Linux does with Device Drivers...

    • Microsoft Windows uses C++ -- albeit with the CRT (C Run Time) library separated.

      The source to ntoskrnl.exe, and the *.sys files it loads, is primarily C++, not C?

  • I started .NET development about 12 years ago and stopped following C++ for that time; previous to that I coded purely in C, both professionally and in my off-time. At that time, I got the impression that C was faster and less prone to quirky, inscrutable API's than C, so I was in agreement with Linus on the decision to remain pure-C.

    How is C++ doing these days with respect to compiler optimization and complexity of available API's?

    • It's more popular than Turbo C.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      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!

    • Re: (Score:2, Interesting)

      by PhrostyMcByte ( 589271 )
      Good C++ is just as fast as good C, and easier for the programmer to optimize. Compiler optimization is on the same level. C++ even allows some interesting things like zero-cost error handling that is actually impossible in C.

      • Re: (Score:2)

        by HiThere ( 15173 )

        Sorry, but C++ literally cannot offer any feature which is impossible in C...except simplicity of source code. C++ source code can often be much simpler than any possible implementation in C, but anything that can be done in C++ can equally be done in C.

        That said, it's often so much simpler to do in C++ that no reasonable person would do the equivalent thing in C.

        • Sorry, but C++ literally cannot offer any feature which is impossible in C

          Apology accepted.

          So when I mentioned zero-cost error handling, I was referring to an exception handling model that keeps all exception handling code -- your entire catch block -- entirely out of your hot path. It can be put in entirely separate cache lines. Basically ensuring that your non-exceptional code is all as close together and fast as possible.

          You can't do this in C. Please prove me wrong! I enjoy learning.

      • Good C++ is just as fast as good C,

        And these days, the simple, idiomatic options in C++ are faster than the simple, idiomatic options in C. The classic example is sort versus qsort, but others abound.

  • Linux could be compiled as C++ (Score:3)

    by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Friday October 03, 2014 @03:07PM (#48058417)

    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.

    • The problem is once you start allow tacit consent for compiling with C++ next thing you know people start either explicitly, or implicitly using C++ features.

      Sad that they felt the stricter type checking wasn't worth it.

  • C++ has its uses... (Score:5, Insightful)

    by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Friday October 03, 2014 @03:19PM (#48058525) Homepage Journal

    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...

    • I disagree, particularly if you include a bit of light template metaprogramming. C++ can enable the compiler to reject bad code which no C compiler could ever know is bad. One example, though a fairly heavyweight one, is that described in Barton and Nackman's "Scientific and Engineering C++". The authors construct a system that enables the compiler to do dimensional analysis on arbitrary expressions involving physical values. There is zero run-time cost, and the infrastructure they create ensures that any a

  • C++ can make sense (Score:3)

    by AaronW ( 33736 ) on Friday October 03, 2014 @03:34PM (#48058627) Homepage

    Back in the 1990s I worked on a large ATM [wikipedia.org] 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.

  • The next Netscape 6. C++ killed Netscape and will kill this idiotic project

  • Linus is right (Score:4, Informative)

    by bms20 ( 827647 ) on Friday October 03, 2014 @03:56PM (#48058779)
    Having spent all week analyzing (and debugging) the mentor graphics usb driver (musb) for the omap processor, I can categorically say that there are some seriously weak drivers in linux.

    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:
    • *Careful programming
    • *Open driver review
    • *Open test suites
      • -For example, the ability to run a verification test to verify that the omap (beagle board) can perform reliable control channel transfers over usb when acting as a peripheral would have saved me a lot of pain.
      • -How about: "Does your RS232 interface work" - hook it to an open test rig, and verify that it can run reliably at 115200 baud for a week. You'd be surprised, but the omap will most likely fail this.

    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

    • Re: (Score:3)

      by Phs2501 ( 559902 )

      Ugh.

      The bloody MUSB driver/OMAP hardware combination caused me to have to write this horrible thing:

      local kmsg = io.open('/proc/kmsg', 'r')
      for line in kmsg:lines() do
      --...
      --elseif line:match('USB IS HORKED %- HELP PLEASE!') then
      ----local reset_usb =
      ------io.open('/sys/devices/platform/<product>-kludges/reset_usb', 'w')
      ----reset_usb:write('1\n')
      ----reset_usb:close()
      ----log.log('Reset USB')
      --end
      end

      ...because some (rare) USB devices would occasionally cause the harware to basically completel

  • Alan Perlis said:

    Everything should be built top-down, except the first time.

    The work on the Linux kernel by Linus is essentially the "first time" which is why he prefers C. It can be used as a bottom-up language. OOP and C++ are top-down. The BOSS-MOOL group are rewriting something that already exists so they are using a top-down approach. Both Linus and the BOSS-MOOL group are using the right tool for the job. The jobs are different so the right tool is different.

  • Skip C++ (Score:3, Funny)

    by Anonymous Coward on Friday October 03, 2014 @05:20PM (#48059339)

    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.

  • The only way to keep kernel relevant (Score:3, Interesting)

    by iamacat ( 583406 ) on Friday October 03, 2014 @07:54PM (#48060347)

    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.

    • Re: (Score:3)

      by itzly ( 3699663 )

      In the end, perhaps Linus should have listened more to Andrew Tanenbaum

      No way. In the end Linus turned out to be right. The only reasonable way to implement all the features of Linux, and with the performance of Linux, is to use a monolithic kernel. And the problem is not the time it takes to pass a message, or the time it takes for a context switch. The biggest problem of a microkernel is to maintain a coherent sense of state among a bunch of distributed processes. As an example, try to imagine a file system as a distributed design.

  • C is better than C++ for the kernel (Score:5, Insightful)

    by emblemparade ( 774653 ) on Saturday October 04, 2014 @12:36AM (#48061257)

    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.

Slashdot Top Deals

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Close