Dbus-Broker 34 Released For High Performance D-Bus Message Broker

[phoronix]

Phoronix: Dbus-Broker 34 Released For High Performance D-Bus Message Broker

There's been nothing new on the BUS1 front this year for capability-based IPC within the Linux kernel... In fact, the BUS1 out-of-tree kernel module has gone untouched for years now. But out of the BUS1 project has been Dbus-Broker for a high performance D-Bus message broker in user-space that doesn't break existing D-Bus compatibility. Out today is the newest version of that project closely tied to systemd developers...

https://www.phoronix.com/news/Dbus-Broker-34

[LuukD]

The thumbnail got me excited for a second: "Could hell have frozen over? Did Linus change his mind over in-kernel D-Bus?"
Not today I'm affraid.

Would anyone of you know if it would be feasible to implement it in eBPF?

[rafanelli]

When systemd was first released, Rust was not yet born. So having that critical piece of system software in C is understandable.

But now, 2023, having another piece of critical system software in C, while Rust is there seems like an odd choice. Maybe C is the "hammer of choice" for the devs.

[jacob]

When systemd was first released, Rust was not yet born. So having that critical piece of system software in C is understandable.

But now, 2023, having another piece of critical system software in C, while Rust is there seems like an odd choice. Maybe C is the "hammer of choice" for the devs.

dbus-broker started development in 2017 IIRC. Rust was nowhere ready for a project like this back then.

[jacob]

The thumbnail got me excited for a second: "Could hell have frozen over? Did Linus change his mind over in-kernel D-Bus?"
Not today I'm affraid.

Would anyone of you know if it would be feasible to implement it in eBPF?

I'm not an expert on eBPF but I really doubt it would be possible. On the plus side, dbus-broker proves that we may not need a kernel-based implementation after all.

[npwx]

The thumbnail got me excited for a second: "Could hell have frozen over? Did Linus change his mind over in-kernel D-Bus?"
Not today I'm affraid.

Nobody ever made a compelling case why this would need to be in the kernel. Also, IIRC, Linus never rejected it, it was always the network developers.

[Rallos Zek]

When systemd was first released, Rust was not yet born. So having that critical piece of system software in C is understandable.

But now, 2023, having another piece of critical system software in C, while Rust is there seems like an odd choice. Maybe C is the "hammer of choice" for the devs.

In 2023 Rust would of be taken more serious if not for the noobs that interject Rust in every conversation out of context.

[jacob]

In 2023 Rust would of be taken more serious if not for the noobs that interject Rust in every conversation out of context.

In 2023 I don't think Rust is exactly lacking in the being taken seriously department.

[jacob]

Nobody ever made a compelling case why this would need to be in the kernel. Also, IIRC, Linus never rejected it, it was always the network developers.

Being in the kernel would have benefits, for example MAC systems like SElinux and Apparmor would naturally cover it.

[EphemeralEft]

I don’t understand why this isn’t the default for all distros that use SystemD. IIRC DBus-Broker requires Linux (so I can appreciate not wanting to add that restriction) but so does SystemD, so that restriction is already there.