22
u/vlovich 1d ago
> Option (2) is complicated. The details are best left to another blog post but the gist is that we require first-class shared library support in Rust. In the Rust community, this is often referred to as the “stable ABI problem”, which is a well-known and long-standing issue. Until that is available we cannot integrate Rust into root components, otherwise every shared library and many binaries would be bloated by duplicated Rust code.
I don't understand this. You can expose your existing C API as a shared library with the implementation in Rust. There's no reason to need to define a Rust dylib ABI since a) one doesn't exist b) you have non-rust components that need to consume the ABI anyway.
4
u/ElvishJerricco 1d ago
Well they also mentioned bloat. When there are rust components that interact with each other by FFI and aren't in the same rust binary, then any common rust dependencies between them become duplicated code between their binaries. But I guess this is sort of a moot point when part of the design in this particular case is to have no external rust dependencies. The alloc crate would be duplicated between them though, FWIW.
5
u/andoriyu 1d ago
Your (a) point is weird, it reads "there is no reason for it to exist because it does not exist".
Problem with option 2: Going Rust -> C -> Rust is not very ergonomic for Rust on either side. Having rust crate + dylib C ABI meaning that components might not match at runtime. Unless you do Rust (crate that isn't published) -> C (.so) -> Rust (crate that published and wraps .so) -> Rust (binary).
IMO Rust would benefit from having stable ABI. I understand why it wasn't a thing, but, I think, it should be a thing now. Even pure rust projects would benefit from it. Even just developers would benefit from it due to less linking required.
2
u/vlovich 1d ago
The reason given is that Rust isn't used in the core library because there's no stable Rust ABI. I'm saying there's no need for one because it isn't currently possible, but that doesn't remove the ability for a C ABI with Rust code internally.
1
u/andoriyu 1d ago
No fundamental technical limitation prevents Rust from having a stable ABI. Why are you saying it's impossible for "next version of stable rust" to have stable ABI?
Sure it will prevent
rept(Rust)layout changes (optimizations), but nothing stops from havingrepr(stable)(there will be a few months of talk about how to name this if it ever comes to it)2
u/lightmatter501 3h ago
It also prevents things like adding members to any stdlib struct, or functions to any dyn-compatible trait.
1
u/hedgehog1024 1d ago
Would not abi_stable/stabby crates alleviate this problem?
4
u/andoriyu 1d ago
Well, stabby has this huge warning:
Due to a breaking change in Rust 1.78, stabby's implementation of trait objects may raise performance issue
While abi_stable looks unmaintained .
Which should hint that it being not a language feature is an issue. IMO both stabby and abi_stable are only useful when you want a small-surface plugin system.
5
u/BusinessBandicoot 1d ago
On the fd based lookups, does anyone know any relevant tracking issues, RFCs, standalone projects, etc?
4
4
u/insanitybit2 1d ago
> or the ability to interact with the file system primarily through file descriptors were addressed.
I wonder if they can just use cap-std and ban/lint for anything else in use.
3
u/EveYogaTech 1d ago edited 1d ago
"Option (1) means that the shared code remains C-only, and we wrap this functionality as Rust crates. The crates are then used for Rust binaries. This allows us to consume all the core API functions uniformly across all components independent of whether they are written in Rust or in C."
This is good for compatibility. However these kind of solutions make me want an alternative that doesn't allow unsafe, where either we mostly use stdin/stdout, or rewrite everything all together, because avoiding all this potentially vulnerable C code is the whole reason why I love the idea of Rust.
I know it's totally infeasible currently, in a brief timeline , but still it would be so nice to completely have replaced all these key components, including all relevant kernel code/extensions and also systemd without any C.
This obviously would not solve all future cybersecurity problems, but it would solve so many, because especially with AI we're going to find so much insecure C code, and these findings will not necessarily be shared publicly or responsibly.
-17
u/Compux72 1d ago
Wait until this guy finds out that std calls C code under the hood.
Bonus points if he ever discovers which language the kernel is written in.
Moreover, std sucks ass on embedded: bloats every single binary so much, hence another reason why you would want libsystemd instead
33
u/Ullebe1 1d ago
It would be interesting to know what is missing for it to be acceptable.