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

81–90 of 102 posts

Re: C++ in the Linux Kernel

#81

Post by [deleted] »

inkyoto wrote: post #79
cesarb wrote: post #69

Earlier quoted context omitted.

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

You are not incorrect, and I shall ruminate on why I had thought that the SysV ABI on i386 used %rax ÷ %rex as input function parameters without having to resort to the use -mpregparm. Thanks for the correction.

[deleted]

Re: C++ in the Linux Kernel

#82

Post by leeter »

tuyiown wrote: post #61
nly wrote: post #33

Earlier quoted context omitted.

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`

I'd say it was extremely intentional given this:

https://lwn.net/ml/linux-api/20180905165436.GA25206@kroah.co...

And that's for a userspace header.

Re: C++ in the Linux Kernel

#83

Post by kaba0 »

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…

Why exactly? They are a compile time concept which only generates code for types where it is needed. That C devs instead copy-paste the same code 10s of times, use some shitty slow linked list, or the worst, use textual macros doesn’t make any of them a better tradeoff imo.

Re: C++ in the Linux Kernel

#85

Post by stonemetal12 »

tialaramex wrote: post #74
pjmlp wrote: post #70

Earlier quoted context omitted.

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

It definitely feels like we're talking past each other. I keep telling you why people think it's a bad idea, and you keep showing that you're allowed to do it anyway. We know. That's the difference between impossible and a bad idea.

You keep saying it is a bad idea like it is a given. He keeps saying 5 bazillion programmers are quite successful with your "bad idea" so maybe it isn't so bad. Is there any evidence either way on the effects of templates on code quality?

Re: C++ in the Linux Kernel

#86

Post by pjmlp »

tialaramex wrote: post #74
pjmlp wrote: post #70

Earlier quoted context omitted.

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

It definitely feels like we're talking past each other. I keep telling you why people think it's a bad idea, and you keep showing that you're allowed to do it anyway. We know. That's the difference between impossible and a bad idea.

Nope, it is the difference regarding politics of what goes into the Linux kernel and the rest of the world, and it is quite clear to which side each of us belong.

Re: C++ in the Linux Kernel

#87

Post by mananaysiempre »

flohofwoe wrote: post #62
pjmlp wrote: 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

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.

Honestly unless you’re on something like an ATtiny with As far as I’ve seen, two things make C and C++ specifically problematic on 8-bitters: automatic promotion to int for all expressions, with int required to be at least 16 bits (a language problem); and subpar codegen on accumulator architectures and other things that are not like desktops (a compiler problem).

Re: C++ in the Linux Kernel

#88

Post by uuidgen »

flohofwoe wrote: post #62
pjmlp wrote: 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

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.

C translates directly to ASM in many cases. It just makes managing offsets and other stuff easier.

C++ adds type-safety on top of that for no cost. It's great when your compiler tells you that there is no operator =|(PORTD, PINA). Did you mean |=(PORTD,PIND) or =|(PORTA,PINA).

Re: C++ in the Linux Kernel

#89

Post by gk1256 »

rramadass wrote: post #77

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…

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.

Re: C++ in the Linux Kernel

#90

Post by mananaysiempre »

uuidgen wrote: post #88
flohofwoe wrote: post #62

Earlier quoted context omitted.

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.

C translates directly to ASM in many cases. It just makes managing offsets and other stuff easier. C++ adds type-safety on top of that for no cost. It's great when your compiler tells you that there is no operator =|(PORTD, PINA). Did you mean |=(PORTD,PIND) or =|(PORTA,PINA).

If you really want that in C, you can either use functions and wrap everything in (incompatible but internally identical) structs, or use Sparse and annotate those integer types to be incompatible. Not that you must prefer that to C++ (even if I do), just to note that you can make do with C if you want to.
Post reply on HN