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

61–70 of 102 posts

Re: C++ in the Linux Kernel

#61

Post by tuyiown »

nly wrote: post #33
monocasa wrote: post #5

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

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

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`

Re: C++ in the Linux Kernel

#62

Post by flohofwoe »

pjmlp wrote: post #38
tialaramex wrote: post #34

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

C++ or even C isn't exactly "fine" on any 8-bit system though. It's nice for a little demo, it can even be tolerable for some real-world projects when mixed with large amounts of inline assembly, but those 8-bit ISAs have been designed mainly for manual assembly coding, not high level compiled languages like C.

Re: C++ in the Linux Kernel

#63

Post by inkyoto »

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.

C++ templates are unwound at the compile time before the «expanded» template code passes along into the optimiser where most of the unused code is elided.

Unless the templates have been externalised (i.e. defined as «extern template …», of course). Even then, a modern compiler+linker combo will optimise most of the unused code away at the linking time thus reducing the final binary size. I do understand that the LTO might not be available for every embedded platform, though.

P.S. That is exactly the point of the C++ template metaprogramming – the hard lifting is delegated to the compiler, which leads to increased compile times but also to more efficient and very compact runtime code.

Re: C++ in the Linux Kernel

#65

Post by gpderetta »

rocqua wrote: post #53
krona wrote: post #44

Earlier quoted context omitted.

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

Compilers can clone functions (so there are two variants with different calling conventions) or even create alternate entry points.

Re: C++ in the Linux Kernel

#66

Post by inkyoto »

10000truths wrote: post #7
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…

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

> The System V i386 ABI passes parameters through the stack.

No. The C/C++ ABI is quite uniform across architectures. The first 1..N (N is ISA dependant) parameters that can fit into a CPU register are passed via registers. The first input parameter that _can't_ fit into a register (e.g. a structure passed by value) is pushed onto the stack, with every other following parameter being pushed onto the stack as well. N+1… parameters are always passed through the stack.

Re: C++ in the Linux Kernel

#67

Post by jcelerier »

rocqua wrote: post #53
krona wrote: post #44

Earlier quoted context omitted.

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

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

Re: C++ in the Linux Kernel

#68

Post by pjmlp »

saagarjha wrote: post #54
pjmlp wrote: post #51

Earlier quoted context omitted.

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 :(

> Devices supported on macOS 11 and later require DriverKit. Use IOKit in your apps and services to discover and use devices.

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

Going forward not for long.

Re: C++ in the Linux Kernel

#69

Post by cesarb »

inkyoto wrote: post #66
10000truths wrote: post #7

Earlier quoted context omitted.

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

> The System V i386 ABI passes parameters through the stack. No. The C/C++ ABI is quite uniform across architectures. The first 1..N (N is ISA dependant) parameters that can fit into a CPU register are passed via registers. The first input parameter that _can't_ fit into a register (e.g. a structure passed by value) is pushed onto the stack, with every other following parameter being pushed onto the stack as well. N+…

> No. The C/C++ ABI is quite uniform across architectures. The first 1..N (N is ISA dependant) parameters that can fit into a CPU register are passed via registers.

Here is the "System V i386 ABI" mentioned above: https://refspecs.linuxfoundation.org/elf/abi386-4.pdf (from https://refspecs.linuxfoundation.org/). It clearly passes all arguments on the stack, and none on registers ("Function Calling Sequence" starting on page 35). That is the ABI used on 32-bit x86 Linux if you don't specify -mregparm (which the kernel uses); since the author was calling the compiler directly (which was necessary because the kernel makefiles only have rules for building C files, not C++ files), there was a mismatch between the -mregparm used by the kernel and the default ABI used by the C++ compiler, which was fixed by also passing -mregparm to the C++ compiler.

Re: C++ in the Linux Kernel

#70

Post by pjmlp »

tialaramex wrote: post #57
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++

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…

Here is another example, running C++ straight on car firmware free of Linux politics via AUTOSAR certification standard.

https://www.parasoft.com/blog/breaking-down-the-autosar-c14-...

But what do they state specifically? Ah, right.

> "The document allows in particular the usage of dynamic memory, exceptions, templates, inheritance and virtual functions."

https://www.autosar.org/fileadmin/user_upload/standards/adap...

Post reply on HN