Toward a better list iterator for the kernel [LWN.net]

Toward a better list iterator for the kernel

Posted Mar 10, 2022 20:04 UTC (Thu) by pankyraghv (subscriber, #153275)
In reply to: Toward a better list iterator for the kernel by pj
Parent article: Toward a better list iterator for the kernel

I know many people in the kernel community hates cpp but I would recommend everyone to take a look at SerenityOS. They have done a fantastic job of rolling out an in-house standard library that actually makes coding in cpp enjoyable (mostly) while reaping the benefits of all the modern features that can catch bugs at compile time. IMO a subset of cpp with a good custom standard library would be a better fit to writing kernel drivers than use something like Rust which has a very different programming paradigm. I also feel something light like Zig might also be a good option.

Toward a better list iterator for the kernel

Posted Mar 13, 2022 10:08 UTC (Sun) by PengZheng (subscriber, #108006) [Link] (3 responses)

Thanks for pointing me to SerenityOS. It seems that memory allocation failure will lead to crash:
https://github.com/SerenityOS/serenity/blob/master/AK/Vec...

I assume (it might be false) that C++ exception is not suitable for kernel development and some constrained embedded environment.
Are there any good guidelines for such C++ usages?

Toward a better list iterator for the kernel

Posted Mar 13, 2022 11:39 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

Basically, anywhere you are hardware-constrained (and an OS is a perfect example) you need to be very careful about knowing exactly what abstractions the compiler is using. C++ makes this rather tricky!

Once you're in user space, especially if you're in an online state (ie the computer is a lot faster than the person behind the keyboard), you no longer need to worry and can use the full power of C++. Just make sure you don't use the bits you don't understand :-)

Cheers,
Wol

Toward a better list iterator for the kernel

Posted Mar 14, 2022 2:26 UTC (Mon) by PengZheng (subscriber, #108006) [Link]

Unfortunately, code size will be a concern, even in user space. Nowadays, devices with 64MB flash storage does a lot of things, doubling code-size as mentioned in ianmcc's comment is terrifying.

Toward a better list iterator for the kernel

Posted Mar 13, 2022 15:43 UTC (Sun) by ianmcc (guest, #88379) [Link]

It depends on how exceptions are implemented by the compiler. Exceptions require RTTI, because you need to be able to match the type of the thrown object with a corresponding catch (...) clause. When you have a try {...} block, the compiler needs to know how to unwind the stack. Most modern compilers use a 'zero overhead' model, meaning that the runtime cost (in CPU time) is basically zero for the no-exception case. ie, there is no penalty for having a try {...} block if no exception is actually thrown. The way they do this is with a lookup table from the instruction pointer to the exception handler for the current stack frame. This basically doubles the code size. Also the cost of throwing an exception is quite high, so you normally only want to do it for really exceptional events, not as an alternative to a return statement. But in some cases exceptions can be faster than return codes, i.e. since you need to check the return code every time, in a tight loop using exceptions might be faster.

More info: https://wg21.link/p1947