10 ms·

C++ in the Linux Kernel

• jayp1418 5y ago
  There should be Ada in Linux kernel
  • Iwan-Zotow 5y ago
    and Haskell
    • FpUser 5y ago
      C'mon people. Python all the way
      • monocasa 5y ago
        The one true language: Threaded INTERCAL.
        • tsimionescu 5y ago
          PLEASE COME FROM HELL
        • inkyoto 5y ago
          PLEASE DO GIVE UP
      • pjmlp 5y ago
        Here, https://blog.adafruit.com/2018/08/10/micropython-for-unified-extensible-firmware-interfaces-uefi/ https://blog.adafruit.com/2018/08/10/micropython-for-unified...
    • _Algernon_ 5y ago
      and blockchain
• qqumut 5y ago
  I guess Rust is far better choise for that.
  • varajelle 5y ago
    Community wise, yes. It seems to have gained some momentum. From a technical point of view, I'm not so sure. C++ still interoperate easier with C than Rust, if only because you can normally just include the headers and be done with it. (Although as the article says, there are some cleanup to do.)
    • broodbucket 5y ago
      From an everything point of view, there's no point in adding complexity for no tangible benefit. Rust has tangible benefits (memory safety). Very far from a silver bullet, but demonstrably better than C. Rust isn't being experimented with in the kernel because someone decided we should really add a second language. C++ interop with C doesn't matter when there's no reason to use C++ in the kernel anyway.
    • tialaramex 5y ago
      The "interoperate easier" idea is a trap for both C and C++ and worth avoiding because in fact they aren't quite compatible, so you're making both languages worse to achieve this. I don't much like C++, but if you must use C++, actually use C++ and forget that it's sorta kinda "compatible" with C.
      • steerablesafe 5y ago
        You can create headers that are usable from C and C++, but you have to actively maintain it that way. As C headers tend to not have function definitions in them, it's fairly easy to avoid the C-only features. I doubt that Linux headers give a damn about usability from C++ though.
      • varajelle 5y ago
        I know they are not 100% compatible, but they are 99% compatible, and that's much better than Rust. It's easy to make it compatible by not using fields called "class", or using #ifndef __cplusplus, most C library headers are actually like that. But not the Linux kernel because they refuse it. That's why I'm saying that the choice is not a technical one.
• monocasa 5y ago
  Lol, part of me likes the effort taken just because, but the kernel devs _really_ do not want C++. One hint: "struct class" https://elixir.bootlin.com/linux/latest/source/include/linux/device/class.h#L54 https://elixir.bootlin.com/linux/latest/source/include/linux...
  • nly 5y ago
    What bothers me about that is that, because C doesn't have namespaces, it's already a terrible name for a struct. What if you want another "class" of thing? Call it device_class ffs
    • deleted 5y ago
      [deleted]
    • tuyiown 5y ago
      You're dismissing the fact that the keyword collision really well might be intentional, the worst of it is that `/sys/class` siblings `bus` and `driver`, if their internal linux rep is actually in the `class.h` siblings, are called `struct bus_type` and `struct device_driver`
      • leeter 5y ago
        I'd say it was extremely intentional given this: https://lwn.net/ml/linux-api/20180905165436.GA25206@kroah.com/ https://lwn.net/ml/linux-api/20180905165436.GA25206@kroah.co... And that's for a userspace header.
  • jerrysievert 5y ago
    as long as nothing you're including includes that in c++, it shouldn't be an issue at the linker level, and thus not be an issue at all. at least in general - if it's something that can't handled by a c shim then you might have an issue.
    • monocasa 5y ago
• jcelerier 5y ago
  > You see the problem. My C++ code expected the calling convention that pushed arguments on the stack, that would be very weird on Linux. The x86_64 linux ABI mandates that the first arguments go on registers afaik (I'm assuming x86_64 here since the post mentions linux distros which are overwhelmingly x64). What compiler would default to a pure stack-based calling convention ? Certainly not GCC or clang, no ? > and the kernel expected my code to pass arguments in the registers. so, how is that a problem with C++ and not the compiler defaults ? > I found the real gold mine of C++ kernel module development knowledge in OSDev.org. They have an entire article on C++ issues. That includes avoiding templates bullshit it is then. https://www.youtube.com/watch?v=A_saS93Clgk https://www.youtube.com/watch?v=A_saS93Clgk if templates are good (sometimes better even) on AVR microcontrollers with memory in kilobytes, there's no reason to not use them in a kernel meant to run on large embedded. Also what's that rant about strings for ? In the end there is zero substance to this article, only very strange rants.
  • 10000truths 5y ago
    > that would be very weird on Linux. The x86_64 linux ABI mandates that the first arguments go on registers afaik (I'm assuming x86_64 here since the post mentions linux distros which are overwhelmingly x64). What compiler would default to a pure stack-based calling convention ? Certainly not GCC or clang, no ? The System V i386 ABI passes parameters through the stack. Perhaps that is what the author is referring to, although I wouldn't be surprised if he mixed it up with the x64 ABI.
    • saagarjha 5y ago
      The 32-bit Linux kernel uses a register-based ABI internally, rather than System V.
    • ivegotnoaccount 5y ago
      In case it is talking about the x64 calling convention, there is actually some kind of an odd case where you would get something that looks like an argument was pushed on the stack: When a non-trivially-copyable object is passed by value to a function, you need to ensure that through the lifetime of the copy, it's address will never change because the constructor may have stored address of some of the field (for instance, a pointer to a field). The way this is handled at list in the SystemV x84_64 ABI is that the object is created on the caller's stack, and a pointer to it is stored in a register, so just like if it was passed as a pointer. I have seen several cases where a header would have an "ifdef c++" clause with copy constructors and destructors in them ("It does not add field so it should be OK, right ?"), which make the object non trivially-copyable, leading to clashing calling convention between C and C++ codes. I am curious about if this may be the issue he encountered.
• jlkjaoifnwlekfj 5y ago
  > A first-year computer science student can tell you that the arguments get pushed onto the stack. In other words, a call to this 3GL function results in the following assembly pseudo code Are people this ignorant when it comes to C/C++ or any systems language? ABI & calling conventions were introduced early in my C & C++ textbooks (age 13 btw, not even close to college years).
  • mhh__ 5y ago
    Ab initio first years probably just about know what registers are so I can believe that. Decoupling the compilers optimizations and the ABI (particularly what constitutes a "move" of a struct) has derailed a few conversations I've been involved with - even from very smart devs (although mainly interpretation rather than basic misunderstandings like thinking what is actually due to the ABI is an optimization)
  • jcranmer 5y ago
    Well, if you believed as the author did that arguments are always pushed onto the stack, you are pretty ignorant--most major architectures these days don't use the stack for arguments, at least not for the first several arguments. (Semi-random tangent: the hardest bug I ever had the pleasure of debugging was when I discovered that the PLT glue code to load an entry into the PLT was unexpectedly clobbering a register that the calling convention said needed to be preserved. By very, very careful using non-default calling conventions across shared object boundaries!)
    • deleted 5y ago
      [deleted]
  • sumtechguy 5y ago
    I think it would depend on which system you were introduced into. Also 99% sure in my classes in the mid 90s they taught stack push. Which made sense as registers were pretty valuable. It was not until RISC came along, and register renaming, that you could consider 'wasting' them on passing args in the general case. In the 'DOS'/'Win16' world calling conventions were all over the place. You could get into trouble real quick if you did not pay attention to those calling convention modifiers. Especially if you were using libs from different compilers. In the linux world where you can control the whole stack it is easier to say 'this way and if you stray away from it, good luck'. Small sample of the remnants of that in the DOS world. https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions?view=msvc-170 https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-an...
• zauguin 5y ago
  > I found the real gold mine of C++ kernel module development knowledge in OSDev.org. They have an entire article on C++ issues. That includes avoiding templates No, it doesn't?!? The linked article mentions templates two times (+ 2 mentions of the standard template library), once saying that templates can be used without further setup and the other times recommending that some template based data structures should be implemented. That's pretty far from "avoiding templates".
• gtqytqyqyq 5y ago
  a complete waste of time
  • opk 5y ago
    If my boss told me to go write a Linux device driver in C++, I'd quietly go away and deliver a working device driver that happens to stick to the C subset of C++. Trying to fiddle about getting header files to include cleanly is a complete waste of time. (Maybe you're referring to something else like reading the article.) The benefits of C++ over C that is consistent and well-written in a disciplined manner is really not as great as many managers have been led to believe. And seeking forgiveness from an idiot manager is always easier than seeking permission to do things sanely.
• rajeevk 5y ago
  In the past, I wrote a unix like kernel from scratch in C++. I have summarized what I had to do to get C++ code run on bare metal in this article https://www.avabodh.com/cxxin/nostdlib.html https://www.avabodh.com/cxxin/nostdlib.html
  • ReaLNero 5y ago
    I've always been interested in writing my own Unix-like kernel! Could you share what resources you used to write it? How long did the whole thing take? Just to understand the scope of the work, did you implement any of the following: memory isolation, networking, concurrency via interleaving on single thread, parallelism where n threads can run n processes simultaneously? How long did each take to get done?
    • rajeevk 5y ago
      I did this while I was doing my bachelor degree course. It was four year course and I started doing this sometime in 2nd year and continued till 4th year. I was not always writing code as I had to study other subjects as well. Also I was just learning coding and other computer science concepts, so it was like learning and writing code. But the writing the kernel forced me to learn many computer science concepts very deeply. At the end, what I had was a kernel which could boot on bare metal (or VM) and provided a command line interface. It had a virtual file system layer and ext2 file systems, process management (fork, exec sys call), memory management (paging and process isolation) and device drivers for keyboard and hard disk. The kernel was able to fork and exec static ELF binary. I did not reach to networking and threading. But that was next step which could make it complete unix kernel. I implemented in bits of assembly(nasm) and C++. So I had to learn runtime and code generation aspect of c++. Based on that learning I wrote this articles on c++ object models and other internals. https://www.avabodh.com/cxxin/cxx.html https://www.avabodh.com/cxxin/cxx.html
• uyt 5y ago
  > Kernel developers obsess about speed and performance. The Linux kernel is built using -mregparm=3, which is sometimes called fastcall. I've never messed with calling convention for the sake of performance before so I found this bit interesting. I found more info about it at: https://en.wikipedia.org/wiki/X86_calling_conventions#Borland_register https://en.wikipedia.org/wiki/X86_calling_conventions#Borlan... Does anyone have benchmarks? Assuming I don't care about ABI stability, what's the fastest calling convention?
  • krona 5y ago
    > Assuming I don't care about ABI stability, what's the fastest calling convention? I'd assume a modern optimizing compiler will, in situations where it's permitted, create completely novel calling conventions depending on the situation. Whole program optimization is one area you might see this.
    • rocqua 5y ago
      The compiler tends to be limited in how it can change calling conventions by external visibility of the functions. Generally if you compile a function down to an object file the compiler will want to make that object file linkable with any other object files importing that symbol properly. Whole program optimization gives the compiler some ways around that. I am not sure how much freedom it gives the compiler.
      • gpderetta 5y ago
        Compilers can clone functions (so there are two variants with different calling conventions) or even create alternate entry points.
      • jcelerier 5y ago
        On Linux with GCC and Clang you can use -fvisibility=internal to tell the compiler to not care at all about this and go wild with ABI. Of course it needs to be done carefully...
      • account42 5y ago
• creamytaco 5y ago
  There's one problem with rants such as these, it's too easy for someone to be exposed as clueless and broadcast his lack of knowledge and assumption-heavy development process to the world. How is that as an advertisement for one's employer?
• nly 5y ago
  These are all standard C and C++ interop problems also found in userland and typically go away if the C project at hand is cooperative.
• rramadass 5y ago
  Valueless Article. Please stop posting these sort of articles which have no information content. The article is merely a rant because the author doesn't have much of an idea of how C++ actually works. Merely knowing the syntax doesn't make one a "C++ programmer" and this is even more true when you are messing around in the Kernel. The article contains no specifics only general statements making me think this was put up to just be a "hit piece".
  • gk1256 5y ago
    With all due to respect, your comment is an anti-specialization rant. > Merely knowing the syntax doesn't make one a "C++ programmer" Does knowing all the possible abstract layers (uh, it's an ocean) make one a C ++ programmer then? > this is even more true when you are messing around in the Kernel It's his right to mess around Kernel and learn things.
    • rramadass 5y ago
      My comment has nothing to do with "anti-specialization" or "right to mess around" anything. The article has zero substance with a generic rant being "i tried to use C++ to write a Kernel Module and ran into problems". There are no specifics w.r.t. C++ nor The Kernel and yet the author blames the C++ Language! Whatever is written up also betrays a certain ignorance of basic C/C++ ABI conventions leading one to surmise that the author is clueless (w.r.t. these two domains). As you can see from other comments in this thread, many others are also of the same opinion while others are guessing all over the map as to what the actual problem might be.
• deleted 5y ago
  [deleted]
• kwertyoowiyop 5y ago
  The article has maybe three paragraphs of actual information.