BUS1 Working On "r-linux" - A Rust Capability-Based Linux Runtime

[phoronix]

Phoronix: BUS1 Working On "r-linux" - A Rust Capability-Based Linux Runtime

BUS1 started out as a Linux kernel IPC module following the failure of KDBUS and while there still are occasional commits to that out-of-tree BUS1 kernel module, the involved (Red Hat) developers have been primarily working on Dbus-Broker as the high performance, user-space D-Bus implementation that delivers greater speed and reliability over the reference D-Bus code. Now also popping up under the BUS1 umbrella is "r-linux" as a Rust-written, capability-based Linux runtime...

https://www.phoronix.com/news/BUS1-r-linux

[tildearrow]

Typo:

R-linux is is triple-licensed under the MIT License, the Apache License Version 2.0, and the GNU Lesser General Public License Version 2.1+.

[cl333r]

But does this have anything to do with BUS1?

[oleid]

But does this have anything to do with BUS1?

It's an user space API.

[archkde]

So I toyed around a bit in the source tree. And it's very weird.

• Most part is a very low-level Rust interface to syscalls, without depending on libc.
• In addition, there are wrappers for exactly three syscalls: fork, exec and restart_syscall. The latter is not normally used in userspace. Furthermore, there are documentation about close() that I have never seen before, and some architecture independent re-exports of some syscall numbers.

So I really wonder what this is going to be. A base for a C-free Rust userspace? A microkernel framework for Linux written in Rust? Feel free to add your own speculations.

[mb_q]

My first though was that it is a compatibility layer allowing to run the same DBUS server code either as an userspace process or a kernel module, but it looks nothing like this, more like an early sketch of an embedded libc (but there are other projects doing "lib-rust", for instance rustix). Maybe to run DBUS super-early after boot, before root final fs is available?

[jacob]

So I toyed around a bit in the source tree. And it's very weird.

• Most part is a very low-level Rust interface to syscalls, without depending on libc.
• In addition, there are wrappers for exactly three syscalls: fork, exec and restart_syscall. The latter is not normally used in userspace. Furthermore, there are documentation about close() that I have never seen before, and some architecture independent re-exports of some syscall numbers.

So I really wonder what this is going to be. A base for a C-free Rust userspace? A microkernel framework for Linux written in Rust? Feel free to add your own speculations.

I'm also puzzled by it and yes, the project looks very embryonic. But presumably they know where they want to go with this and the idea and vision has yet to be explained.

[oiaohm]

Remember dbus1 is the home of dbus-broker if there is any plans to make a rust version of dbus-broker wrapping on top of glibc really would not make sense as you are adding overhead.

Also committing to offer a rust based version of dbus-broker without a direct to kernel rust implementation bench-marked and tested would be foolishness.

Yes I would say embryonic is correct.

https://github.com/rust-lang/rfcs/issues/2610

There are a long list of parties who look at rust implementations in userspace depending on a libc to work as problematic. Yes its one of those funny locations rust is solid as a item to replace C and C++ then goes and is depending on platform libc as soon as you make a program in most cases. I would say rust is still in embryonic state itself it need to break out of it shell and grow up. Go and other programming language went though the same process of depending on a libc before it got its direct to platform syscall and native own library support.

https://kobzol.github.io/rust/ci/2021/05/07/building-rust-binaries-in-ci-that-work-with-older-glibc.html

Yes the same evil headache we have with C programs on linux happens with rust programs because of depending on some libc problem.

This is one of those not solved yet problems of rust. This is not just a embryonic problem at dbus1 its a embyronic problem with rust in general.

Do remember klibc exists with linux as a light weight libc for system core items that happen to be used in the initramfs and other places where glibc would be too heavy. Guess what current day rust does not support klibc. Yes dbus-broker is something you might want to start really early..

[coder]

But does this have anything to do with BUS1?

If I understand correctly, r-linux merely added bindings for BUS1? That would be good news for BUS1, as it could suggest they believe the project may still have a future.

[oiaohm]

If I understand correctly, r-linux merely added bindings for BUS1? That would be good news for BUS1, as it could suggest they believe the project may still have a future.

There are not bus1 bindings in r-linux. So far r-linux is a very limit subset of Linux syscalls and only has x86 and x86-64 support.

I would say this is still very prototype.