Dbus-Broker Is Still A Faster User-Space-Based D-Bus

[NotMine999]

2 of 7 links don't point back to phoronix, is anything ok over there?

You mean to say Phoronix is starting to include links to articles other than it's own?

Somebody please check to see if the end of the world is imminent!!

[ehansin]

Michael, they give you a hard time here, don't they

[Naib]

Dbus-Broker Is Still A Faster User-Space-Based D-Bus

Yes dbus-broker
1) depends on systemd
2) depends on dbus

emerge dbus-broker -va

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-apps/systemd-239-r1:0/2::gentoo  USE="acl gcrypt kmod lz4 pam pcre policykit resolvconf seccomp split-usr ssl sysv-utils -apparmor -audit -build -cryptsetup -curl -elfutils -gnuefi -http -idn -importd -libidn2 -lzma -nat -qrcode (-selinux) -test -vanilla -xkb" ABI_X86="32 (64) (-x32)" 7,004 KiB
[ebuild  N     ] sys-apps/gentoo-systemd-integration-7::gentoo  63 KiB
[ebuild   R    ] sys-apps/dbus-1.12.10::gentoo  USE="X systemd* -debug -doc -elogind (-selinux) -static-libs -test -user-session" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild  N     ] sys-apps/dbus-broker-15::gentoo  USE="launcher -audit -doc (-selinux)" 305 KiB
[blocks B      ] sys-apps/sysvinit ("sys-apps/sysvinit" is blocking sys-apps/systemd-239-r1)
[blocks B      ] sys-fs/eudev ("sys-fs/eudev" is blocking sys-apps/systemd-239-r1, sys-apps/gentoo-systemd-integration-7)
[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/eudev-3.2.6)
[blocks B      ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/eudev-3.2.6)

seems like a nice tautology ... dbus-broker a better dbus but needs dbus to function

[ssokolow]

seems like a nice tautology ... dbus-broker a better dbus but needs dbus to function

It's likely that "sys-apps/dbus" is needed because it contains multiple components, not all of which dbus-broker reimplements. (eg. both a daemon and client libraries)

[ssokolow]

nobody figured that out except you. reimplementing dbus daemon does not make context switches magically go away, so they still present performance problem

The point was that bad design caused far more slow-down than the presence of context switches.

(eg. If you have a program that's slow because you're calling read(fd, buf, 1); a million times, the solution isn't to redesign read so it doesn't need context switches. The solution is to batch up your reads with something like read(fd, buf, 65535);.)

[pal666]

The point was that bad design caused far more slow-down than the presence of context switches.

(eg. If you have a program that's slow because you're calling read(fd, buf, 1); a million times, the solution isn't to redesign read so it doesn't need context switches. The solution is to batch up your reads with something like read(fd, buf, 65535);.)

but that program didn't do read million times, so reducing number of context switches is still required

[smitty3268]

but that program didn't do read million times, so reducing number of context switches is still required

Which is what redesigning the API would do.

The only argument for putting it in the kernel was that they wanted to retain backwards compatibility and not change the API. That makes sense, but it's a tough argument to make that it's worth sticking a bad API into the kernel just to avoid fixing it.

[jacob]

Which is what redesigning the API would do.

The only argument for putting it in the kernel was that they wanted to retain backwards compatibility and not change the API. That makes sense, but it's a tough argument to make that it's worth sticking a bad API into the kernel just to avoid fixing it.

That is a fair point however I think it's still a worthwhile goal to eventually merge low-level DBUS support (in whatever form) into the kernel. One reason is security; DBUS objects/interfaces should ideally be exposed as kernel objects (e.g. file descriptors) so that kernel-level access control, confinement, auditing etc. naturally extend to them. For example, being able to specify DBUS permissions and/or restrictions in an apparmor profile would be really useful, wouldn't it?

Another reason is that as long as the kernel has no knowledge of the IPC semantics, there is basically no way to avoid the priority inversion problem.

[nanonyme]

Yes dbus-broker
1) depends on systemd
2) depends on dbus

emerge dbus-broker -va

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] sys-apps/systemd-239-r1:0/2::gentoo USE="acl gcrypt kmod lz4 pam pcre policykit resolvconf seccomp split-usr ssl sysv-utils -apparmor -audit -build -cryptsetup -curl -elfutils -gnuefi -http -idn -importd -libidn2 -lzma -nat -qrcode (-selinux) -test -vanilla -xkb" ABI_X86="32 (64) (-x32)" 7,004 KiB
[ebuild N ] sys-apps/gentoo-systemd-integration-7::gentoo 63 KiB
[ebuild R ] sys-apps/dbus-1.12.10::gentoo USE="X systemd* -debug -doc -elogind (-selinux) -static-libs -test -user-session" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild N ] sys-apps/dbus-broker-15::gentoo USE="launcher -audit -doc (-selinux)" 305 KiB
[blocks B ] sys-apps/sysvinit ("sys-apps/sysvinit" is blocking sys-apps/systemd-239-r1)
[blocks B ] sys-fs/eudev ("sys-fs/eudev" is blocking sys-apps/systemd-239-r1, sys-apps/gentoo-systemd-integration-7)
[blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/eudev-3.2.6)
[blocks B ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/eudev-3.2.6)

seems like a nice tautology ... dbus-broker a better dbus but needs dbus to function

It does need Dbus to function but not dbus-daemon. See the dbus-broker feature by default feature in Fedora 30, that involves packaging changes in Dbus

[Ananace]

Yes dbus-broker
1) depends on systemd
2) depends on dbus

emerge dbus-broker -va

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] sys-apps/systemd-239-r1:0/2::gentoo USE="acl gcrypt kmod lz4 pam pcre policykit resolvconf seccomp split-usr ssl sysv-utils -apparmor -audit -build -cryptsetup -curl -elfutils -gnuefi -http -idn -importd -libidn2 -lzma -nat -qrcode (-selinux) -test -vanilla -xkb" ABI_X86="32 (64) (-x32)" 7,004 KiB
[ebuild N ] sys-apps/gentoo-systemd-integration-7::gentoo 63 KiB
[ebuild R ] sys-apps/dbus-1.12.10::gentoo USE="X systemd* -debug -doc -elogind (-selinux) -static-libs -test -user-session" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild N ] sys-apps/dbus-broker-15::gentoo USE="launcher -audit -doc (-selinux)" 305 KiB
[blocks B ] sys-apps/sysvinit ("sys-apps/sysvinit" is blocking sys-apps/systemd-239-r1)
[blocks B ] sys-fs/eudev ("sys-fs/eudev" is blocking sys-apps/systemd-239-r1, sys-apps/gentoo-systemd-integration-7)
[blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/eudev-3.2.6)
[blocks B ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/eudev-3.2.6)

seems like a nice tautology ... dbus-broker a better dbus but needs dbus to function

You can emerge it without the "launcher" USE-flag to not install the systemd unit, that would also drop the explicit dependency on dbus at the same time.
You wouldn't be able to use the launcher feature (dbus-broker as only the user bus implementation) without systemd anyway, no other service manager has support for user service management after all.