Updated Rust Code For Linux Kernel Patches Posted

[bug77]

When it comes to the Linux kernel there is such thing as Linux kernel C.

https://www.kernel.org/doc/html/latest/dev-tools/sparse.html

Yes you have a static analyser with the Linux kernel that you have to add annotations to your C code so your C code is acceptable. Yes those annotations for sparse can at times make it tricker to take code from the Linux kernel and put them in a different OS that is general C kernel.

Yes there are quite a few faults that you can code in general C that when you run builds with Linux with sparse on come build failures with the Linux kernel. So mainline Linux kernel C does not have the same list of failures as normal C and part because the Linux kernel C is extended.

The mere fact that those hoops even exist for you to jump through, is a testament to C's shortcomings. I don't want tot talk down C, it has carried us for half a century. That in itself ensures it will be forever remembered - and it's not done yet, it's got at least a couple more decades of life left in it. But with half a century of hardware and software/compiler advancements, I'm not surprised it may be time to move on.

[moltonel]

But there is still the problem of needing C developers going forwards to maintain core parts and nothing of these changes so far will make that code more readable to developers who are skilled in rust but not C. Time will tell if rust long term for the linux kernel is a benefit or harm.

The kernel is a vast project with many different areas that require specific knowledge, regardless of the implementation language. Nobody is skilled enough to touch everything, and most contributors are productive while understanding only a small subset. The same will be true for Rust contributors, they are likely to focus on particular subsystems. That doesn't reduce the amount of contributors to other C-only subsystems, this isn't a zero-sum game.

Really I would have liked to see sparse the static checking program of the Linux kernel over C parts gain more and more ways to checking for faults in the Linux kernel version of C that rust forbids. Yes this would lead to more rust like annotation in the C code so making it simple for rust developer to understand the C code.

The introduction of Rust doesn't stop other kernel hardening projects, there is a huge investment in Linux security, Rust is just one aspect of it.

[intelfx]

This is simply due to the fact that the Rust standard library is always linked statically <...>

It's actually because Rust statically links stdlib. <...>

I believe this is exactly what I said?

[ferry]

Phoronix: Updated Rust Code For Linux Kernel Patches Posted

...Linus Torvalds is not opposed to it,...

https://www.phoronix.com/scan.php?pa...t-For-Linux-v2

Ferry is opposed to it.

[Mario Junior]

There are some problems with the Rust language:

• Long compile times / slow build
• The resulting binary produced is large
• You cannot declare async functions inside a trait
• Libraries built using a async runtime are incompatible with other libraries built using a different async runtime

And almost of things written in rust is "unsafe". The "muuhhh rust is more safe bla bla bla" is just a fucking meme.

[dremon_nl]

There are some problems with the Rust language:

• Long compile times / slow build
• The resulting binary produced is large
• You cannot declare async functions inside a trait
• Libraries built using a async runtime are incompatible with other libraries built using a different async runtime

• Slow build is mostly a perception because it builds all dependencies from sources rather than links binaries. If you let your C or C++ project to fully compile all those 3rd-party modules the build times will be an order of magnitude higher (especially for stuff like Boost).
• This is true only for small or trivial projects which are often used to compare binary sizes. Rust links it's standard library statically. C and C++ usually links everything dynamically. For larger apps the difference is not that big. Static linking has a lot of pros (and certainly cons).
• Yes, this is one of the most wanted feature. I think it's being worked on. You can though with `async_trait` but it uses boxing.
• Many runtimes provide compatibility layers

Rgds

[dremon_nl]

And almost of things written in rust is "unsafe". The "muuhhh rust is more safe bla bla bla" is just a fucking meme.

Not really. Unsafe code is isolated with `unsafe` keyword whereas the entire C/C++ app is unsafe. Most of things written in Rust and published on crates.io are just the opposite, e.g. safe.

[cl333r]

There are some problems with the Rust language:

• Long compile times / slow build
• The resulting binary produced is large
• You cannot declare async functions inside a trait
• Libraries built using a async runtime are incompatible with other libraries built using a different async runtime

Rust also inserts panicking code instead handing the problem over to the user. I remember Linus raising this issue.
Also, did Rust solve its memory allocation behavior - when it fails to allocate memory to an object it shouldn't panic, the user should handle it graciously.

[tildearrow]

There are some problems with the Rust language:

• Long compile times / slow build

• This is because Rust has to compile every crate/library for some unknown reason. Would be nice to have a cache though...
  
  

• The resulting binary produced is large