D-Bus Implementation Aiming For The Linux Kernel

[Ericg]

"Theoretically", ok lets say a lot faster, but I don't think dbus is too slow now.

No but its also the issue of finally getting Kernel-IPC "right." If we had gotten IPC right the first time we wouldn't have required AF_BUS or Dbus, since we DID come up with those 2 followups there's obviously something wrong with whatever the current implementation is. Going with dbus has the added bonus of speeding up any dbus-enabled program which is.... all of Gnome, KDE, XCFE, any program designed FOR those DE's...do you see a pattern forming? Pretty sure Greg has a phoronix account, I'd love for him to post the exact downsides of the current IPC mechanism.

[Akka]

I thought it was related to the sandboxing stuff phoronix wrote about some days ago?


Besides that is systemd qualified to be "Minimal dependencies and footprint (does not require POSIX shell or D-Bus)" in the openrc article on Wikipedia now

[LightBit]

Theoretically twice as fast since it would cut the amount of mem-copy's in half and a copy is about the most expensive thing you can do in software...

"Theoretically", ok lets say a lot faster, but I don't think dbus is too slow now.

[Ericg]

Why? dbus daemon works. This will only make dbus little faster.

Theoretically twice as fast since it would cut the amount of mem-copy's in half and a copy is about the most expensive thing you can do in software...

[LightBit]

But this is not bloat, but something needed. I think it will make everyone's life easier (if Linus won't burn this idea with fire).

Why? dbus daemon works. This will only make dbus little faster.

[HyperDrive]

Could this replace Binder (on Android)...?

Funny, you are comparing it to BSD.
BSD has dbus equivalent, it's dbus daemon (like Linux has now).
Bloat in kernel space is much worse than in user space.

But this is not bloat, but something needed. I think it will make everyone's life easier (if Linus won't burn this idea with fire).

[LightBit]

And such approach will make Linux more feature rich, so you can't really compare it to BSD when comes to such aspect of bloat, because you have to add dbus equivalent to BSD first.

Funny, you are comparing it to BSD.
BSD has dbus equivalent, it's dbus daemon (like Linux has now).
Bloat in kernel space is much worse than in user space.

[LightBit]

It sounds funny in BSD guy mouths. This approach will make Linux closer to BSD when comes to having core not spread in the wilds. Merging things like dbus will simplify other things a lot and I hope they'll do something similar with glibc or even systemd. BSD is bloated, because it can't even run on mobiles and it's slower.

I'm not really "BSD guy".
They are not merging it into same tree (like BSDs have), but into kernel space.
BSD is less bloated than Linux, of course it has less features too. BSD can run on small devices. Yes, it's usually little slower, because it's less optimised (bad SMP).

We need to merge Gnome, systemd, ... into kernel and make Linux even more bloated.

It sounds funny in BSD guy mouths. This approach will make Linux closer to BSD when comes to having core not spread in the wilds. Merging things like dbus will simplify other things a lot and I hope they'll do something similar with glibc or even systemd. BSD is bloated, because it can't even run on mobiles and it's slower. And such approach will make Linux more feature rich, so you can't really compare it to BSD when comes to such aspect of bloat, because you have to add dbus equivalent to BSD first.