Rust WQ Abstractions, Rust Toolchain Upgrade & Android Kernel Builds For Linux 6.7

[phoronix]

Phoronix: Rust WQ Abstractions, Rust Toolchain Upgrade & Android Kernel Builds For Linux 6.7

Merged one year ago was the initial Rust code for the Linux kernel back in Linux 6.1. We're now up to the Linux 6.7 development cycle and the enabling of more kernel functionality so it can be used/accessed from Rust code remains ongoing along with continuing to bump the base toolchain requirements and other functionality to make it more practical to write future Linux device drivers within this memory safe programming language...

https://www.phoronix.com/news/Linux-6.7-Rust

[kpedersen]

Rust WQ Abstractions

Bindings... Time-consuming to write. Time-consuming to maintain.

[ssokolow]

Bindings... Time-consuming to write. Time-consuming to maintain.

Except that Rust isn't that far from C++ as far as how easily you can call C APIs and, in practical terms, "bindings" in the context of Rust means "we've finally found a way to design memory-safety annotations for C that people won't just lazy out of writing like they do with things like splint".

The primary purpose of bindings from Rust to C is to augment the C code with the information the Rust compiler needs to automatically catch misuse of the APIs.

To say bindings are time-consuming to write and maintain in this context is sort of like saying "Public health care will cost ... billion over 10 years" while neglecting to mention that the cited number is less than the cost of the system it's proposed to replace.

[bug77]

Bindings... Time-consuming to write. Time-consuming to maintain.

Your vastly superior solution for this being...?

[kpedersen]

Your vastly superior solution for this being...?

Th one that is already in vast use. Obviously C.

Except that Rust isn't that far from C++ as far as how easily you can call C APIs

You have tried both right?

Rust's approach is the same as i.e Python and binding generation via Swig. This is nothing like the bindingless C++ approach.

"Public health care will cost ... billion over 10 years and then once the bindings are complete then we can maintain the bindings"

[gavron]

Bindings... Time-consuming to write. Time-consuming to maintain.

No no, just write them in Rust.

My dog was sick the other day and I told the vet to redo him in Rust. Now he's all better, and memory-safe too!
Tomorrow I'm picking up my new toothpaste -- RustBright! My mouth will be all clean, and memory-safe. Not so sure about those metal fillings with rust...

[darkonix]

No no, just write them in Rust.

My dog was sick the other day and I told the vet to redo him in Rust. Now he's all better, and memory-safe too!
Tomorrow I'm picking up my new toothpaste -- RustBright! My mouth will be all clean, and memory-safe. Not so sure about those metal fillings with rust...

Now I want to call my next dog Rusty ;-)

[bug77]

Th one that is already in vast use. Obviously C.

C? Vastly superior? In 2023?
Good one.

[pong]

Bindings... Time-consuming to write. Time-consuming to maintain.

It's bad enough for C/C++.
I'm still lost wrt. what the "plan" is for actually being able to write ~fully functional Android applications that use the android "java" APIs from Rust.
Obviously the JNI stuff is there but talk about binding / proxy time consuming bloat to write / maintain.
Maybe the theory is one shouldn't try to do Rust/"JVM"/VM interop beyond what's already done with JNI, or the theory is that
if one does one can import some 3rd party OSS library of API wrappers/proxies to interop with various android subsystem APIs etc.

It's still kind of a tower of babylon with VM based languages and then bare-ish metal languages C/C++/rust in some target flows and then the scripted languages Python/JS and then the CLR C# etc. stuff.

It'd be nice to have some kinds of either standardized or auto-generated interop layers (obviously there's SWIG and stuff but....not frictionless / elegant) for all this stuff.

On that front GraalVM etc. is interesting but useless if one is talking about targeting random desktop apps or android / mobile stuff.
At least there's WASM but that's for runtime coexistence of separate domains sort of and not call-API interop between multi-lingual domains / libraries / ecosystems.

I guess some kind of cool RPC API layer that could compile down to either tiny native glue functions when possible all the way up to high level wrapper / facade pattern stuff where necessary seems to be "missing" from some of these different language ecosystems to unify their ability to interop code in whatever language for whatever runtime sanely.

[pong]

Except that Rust isn't that far from C++ as far as how easily you can call C APIs and, in practical terms, "bindings" in the context of Rust means "we've finally found a way to design memory-safety annotations for C that people won't just lazy out of writing like they do with things like splint".

The primary purpose of bindings from Rust to C is to augment the C code with the information the Rust compiler needs to automatically catch misuse of the APIs.

To say bindings are time-consuming to write and maintain in this context is sort of like saying "Public health care will cost ... billion over 10 years" while neglecting to mention that the cited number is less than the cost of the system it's proposed to replace.

You're right.

Of course it's even "worse" than RUST/C, the C-to-C++ interop and C++ ABI stuff is bad enough that the kernel is still stuck in C/Rust and not C++ so clearly there's a lot of possible friction in crossing language "boundaries" even with languages that could / should "play nicely together" easily.

Anything that helps facilitate / mandate basic type / memory safety in programming is a good / necessary thing, though, and C / original C++ haven't gone far enough fast enough for that though we're getting there with C++ though there's still arithmetic safety TBD and also that some of the GSL / static analysis stuff needed to make the kinds of memory safety / sanitizer/ SCA constructs e.g. Sutter / Stroustrup proposed aren't ubiquitously standardized / supported in multi-platform tools.

And then there's other upstart stuff like Carbon trying to be open to address the same weaknesses.

In some ways the ADA / ERLANG / HASKELL still have better elements than what we're most commonly using in terms of languages / tools / safety / patterns.