Re: [GIT PULL] kdbus for 4.1-rc1

Martin Steigerwald
2015-04-29T15:28:05Z

Am Mittwoch, 29. April 2015, 14:47:53 schrieb Harald Hoyer:
> We really don't want the IPC mechanism to be in a flux state. All tools
> have to fallback to a non-standard mechanism in that case.
>
> If I have to pull in a dbus daemon in the initramfs, we still have the
> chicken and egg problem for PID 1 talking to the logging daemon and
> starting dbus.
> systemd cannot talk to journald via dbus unless dbus-daemon is started,
> dbus cannot log anything on startup, if journald is not running, etc...

Do I get this right that it is basically a userspace *design* decision
that you use as a reason to have kdbus inside the kernel?

Is it really necessary to use DBUS for talking to journald? And does it
really matter that much if any message before starting up dbus do not
appear in the log? /proc/kmsg is a ring buffer, it can still be copied over
later.

I remember this kind of reason not not having cgroup management in a
separate process, but these are both in userspace.

"We have done it this way in userspace, thus this needs to be in kernel"
doesn´t sound quite convincing to me as an argument for having dbus inside
the kernel. Userspace uses the API the kernel and glibc provide, yes, it
makes sense to look at what userspace needs, but designing some things in
userspace and then requiring support for these design decisions in the
kernel just doesn´t sound quite right to me.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7