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

Toward a better list iterator for the kernel

Posted Mar 10, 2022 16:06 UTC (Thu) by pj (subscriber, #4506)
Parent article: Toward a better list iterator for the kernel

I read part of that thread and what came to mind to me was that the devs were fighting the C preprocessor, and I was reminded of Zig trying to basically be (arguably) C without the cpp. Maybe once it's done Zig will manage to make it into the kernel - it's a better candidate than Rust, IMO, being much more C-like and having full C binary compatibility.

to post comments

Toward a better list iterator for the kernel

Posted Mar 10, 2022 20:04 UTC (Thu) by pankyraghv (subscriber, #153275) [Link] (5 responses)

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 11, 2022 18:55 UTC (Fri) by timon (subscriber, #152974) [Link]

As I read this, you misunderstood the "cpp" part; the OP is talking about the C preprocessor and you are talking about C++.

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

Toward a better list iterator for the kernel

Posted Mar 10, 2022 21:47 UTC (Thu) by bartoc (guest, #124262) [Link]

I'm concerned about how long zig tends to defer typechecking of code. Maybe it doesn't matter in the real world though.

I really love how zig does generics; you write type constructors as just .... normal functions that return a type!

Toward a better list iterator for the kernel

Posted Mar 10, 2022 22:47 UTC (Thu) by roc (subscriber, #30627) [Link]

The main point of Rust in the kernel is to get much-improved safety properties. Zig doesn't provide that.