Live data from Hacker News

C++ in the Linux Kernel

threatstack.com

41–50 of 102 posts

Re: C++ in the Linux Kernel

#41

Earlier quoted context omitted.

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

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.

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.

Re: C++ in the Linux Kernel

#42

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

AVRs don't have enough storage for templated code to explode into an unmanageable problem.

What do templates have to do with storage, though? My primary attraction to C++ templates is that they let me write very expressive code that will compile down to a handful of instructions. Now, actually compiling complex C++ templates on a storage-constrained system can be a problem, since templates are compile-time beasts, not runtime. Once compiled, though, they have a Cheshire-cat existence.

Edit: Unless you're doing something rather silly with the templates, but again, that's not a template problem.

Re: C++ in the Linux Kernel

#43
post #27

Earlier quoted context omitted.

AVRs don't have enough storage for templated code to explode into an unmanageable problem.

Somehow C64 can deal with them. "CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”" https://www.youtube.com/watch?v=zBkNBP00wJE "C++20 For The Commodore 64" https://www.youtube.com/watch?v=EIKAqcLxtT0

I love these videos, Jason is doing fantastic work with his YouTube channel and C++ Weekly series.

Re: C++ in the Linux Kernel

#44
post #28

> 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#Borlan... Does anyone have benchmarks? Assuming I don't care about ABI stability, what's…

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

Re: C++ in the Linux Kernel

#45
post #24

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

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?

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

Re: C++ in the Linux Kernel

#46
post #38

Earlier quoted context omitted.

But a C64 is still only talking about 64kB of RAM. The post you're replying to claims that Template complexity gets unreasonable on a large machine, such as a Linux system. Not sure I agree, but "it's fine on a C64" isn't evidence in your favour unless you've forgotten Linux doesn't even run on a Commodore 64.

So it is fine on a 64KB system, but unmanageable on a platform that gets all the different kinds of boilerplate to run cloud workloads, got it

I mean, apparently this is confusing, but yes, obviously.

If your Commodore 64 template is dealing with say, foozles that might be 8-byte, 12-byte or 16-byte, the complexity incurred is pretty small, bugs with foozle are likely to be something mere mortals can understand and fix.

On a more complicated system like a cloud Linux setup the template may be for foozles that can be in any colorspace and on a remote machine or locally, and now sometimes the bug with foozle involves a fifty line error message because the compiler doesn't realise all that happened is you meant to write foozle ...

It's not even as if the C++ committee isn't aware that templates are a problem. Remember template meta-programming wasn't really intended from the outset, and a big part of the point of Concepts was to at last let you write code that compilers can provide readable errors for when it's wrong.

Re: C++ in the Linux Kernel

#47
post #43
post #27

Earlier quoted context omitted.

Somehow C64 can deal with them. "CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”" https://www.youtube.com/watch?v=zBkNBP00wJE "C++20 For The Commodore 64" https://www.youtube.com/watch?v=EIKAqcLxtT0

I love these videos, Jason is doing fantastic work with his YouTube channel and C++ Weekly series.

Check his CppCon 2021 presentation, done on a C64 emulator thanks constexpr. :)

Re: C++ in the Linux Kernel

#48
post #38

Earlier quoted context omitted.

So it is fine on a 64KB system, but unmanageable on a platform that gets all the different kinds of boilerplate to run cloud workloads, got it

I mean, apparently this is confusing, but yes, obviously. If your Commodore 64 template is dealing with say, foozles that might be 8-byte, 12-byte or 16-byte, the complexity incurred is pretty small, bugs with foozle are likely to be something mere mortals can understand and fix. On a more complicated system like a cloud Linux setup the template may be for foozles that can be in any colorspace and on a remote machine…

The whole issue with Linux and C++ is political, there are other OSes that don't suffer from such issues and gladly accept templates.

https://developer.apple.com/documentation/driverkit

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-...

https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...

https://genodians.org/nfeske/2019-01-22-conscious-c++

Re: C++ in the Linux Kernel

#49
post #48

Earlier quoted context omitted.

I mean, apparently this is confusing, but yes, obviously. If your Commodore 64 template is dealing with say, foozles that might be 8-byte, 12-byte or 16-byte, the complexity incurred is pretty small, bugs with foozle are likely to be something mere mortals can understand and fix. On a more complicated system like a cloud Linux setup the template may be for foozles that can be in any colorspace and on a remote machine…

The whole issue with Linux and C++ is political, there are other OSes that don't suffer from such issues and gladly accept templates. https://developer.apple.com/documentation/driverkit https://docs.microsoft.com/en-us/cpp/build/reference/kernel-... https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/... https://genodians.org/nfeske/2019-01-22-conscious-c++

To be fair, DriverKit runs in userspace. IOKit, its spiritual predecessor, only allowed for the use of Embedded C++.

Re: C++ in the Linux Kernel

#50

Earlier quoted context omitted.

AVRs don't have enough storage for templated code to explode into an unmanageable problem.

What do templates have to do with storage, though? My primary attraction to C++ templates is that they let me write very expressive code that will compile down to a handful of instructions. Now, actually compiling complex C++ templates on a storage-constrained system can be a problem, since templates are compile-time beasts, not runtime. Once compiled, though, they have a Cheshire-cat existence. Edit: Unless you're d…

The general complaint with templates is they are instantiated and if you’re not careful can bloat the binary with multiple versions of a piece of code. But this is usually something pretty easy to solve: just don’t do something that would cause that to happen :P
Post reply on HN