Re: [GIT PULL] kdbus for 4.1-rc1

[Martin Steigerwald <martin@lichtvoll.de>]

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