Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ in the Linux Kernel

threatstack.com

Post reply on HN
Print view View original

51–60 of 102 posts

Re: C++ in the Linux Kernel

#51

Post by pjmlp »

saagarjha wrote: post #49
pjmlp wrote: post #48

Earlier quoted context omitted.

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

True, but that isn't the case for the other more modern examples.

Also IO Kit is no more, unless one is running an outdated macOS installation.

And talking about the past, maybe discussing about dynamic dispatch of Objective-C messsages on NeXTSTEP drivers with the previous Driver Kit, would also be quite interesting regarding "bloat".

Re: C++ in the Linux Kernel

#53

Post by rocqua »

krona wrote: post #44
uyt wrote: 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.

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.

Re: C++ in the Linux Kernel

#54

Post by saagarjha »

pjmlp wrote: post #51
saagarjha wrote: post #49

Earlier quoted context omitted.

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

True, but that isn't the case for the other more modern examples. Also IO Kit is no more, unless one is running an outdated macOS installation. And talking about the past, maybe discussing about dynamic dispatch of Objective-C messsages on NeXTSTEP drivers with the previous Driver Kit, would also be quite interesting regarding "bloat".

IOKit remains the only way to write kernel extensions, which are still supported but discouraged if DriverKit does the job. NeXtTSTEP using Objective-C for drivers was certainly very cute but I guess they just didn’t want to have driver makers learn the language :(

Re: C++ in the Linux Kernel

#55

Post by qalmakka »

kevin_thibedeau wrote: post #25
jcelerier wrote: post #6

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

I have _never_ had any issue with C++ templates on _modern_ µControllers such as the ESP32. Unless you have an incredibly minuscule flash, modern GCC or LLVM are very good at deleting unused code when you compile everything with -Os. Even -Og isn't that critical either.

Re: C++ in the Linux Kernel

#56

Post by [deleted] »

jcranmer wrote: post #15
jlkjaoifnwlekfj wrote: post #10

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

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…

[deleted]

Re: C++ in the Linux Kernel

#57

Post by tialaramex »

pjmlp wrote: post #48
tialaramex wrote: post #46

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

I understand that for C++ programmers "That's possible" versus "That's a good idea" is a distinction without a difference, however for the rest of us the fact you can use templates as much as you like in, say, Windows drivers, does not magically mean it's a good idea to write complex templated code in Windows drivers.

The constraints in /kernel like forbidding exceptions are because otherwise they (Microsoft) need to do a bunch of extra work to support your bad idea. But your use of templates has no impact on their work, so knock yourself out adding as much complexity as you like this way.

Re: C++ in the Linux Kernel

#58

Post by varajelle »

tialaramex wrote: post #39
varajelle wrote: post #17

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.

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.

Re: C++ in the Linux Kernel

#59

Post by pajko »

saagarjha wrote: post #8
jcelerier wrote: post #6

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

Perhaps the article is old enough to have been written in the 32-bit era?

The LDD3 mentioned is 32-bit era, and 2.6.x kernel, which had a CONFIG_REGPARM to allow passing parameters in registers (because the default was not to do that).
Post reply on HN