Message-ID: <64569721-A266-4196-BDD2-1336E379BB6B@xmission.com>
Date:	Thu, 30 Apr 2015 15:14:02 -0500
From:	"Eric W. Biederman" <ebiederm@...ssion.com>
To:	Harald Hoyer <harald@...hat.com>, John Stoffel <john@...ffel.org>,
	Havoc Pennington <hp@...ox.com>
CC:	Theodore Ts'o <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Lukasz Skalski <l.skalski@...sung.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1



On April 29, 2015 7:47:53 AM CDT, Harald Hoyer <harald@...hat.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>On 29.04.2015 01:12, John Stoffel wrote:
>> LDAP is pretty damn generic, in that you can put pretty large objects
>into
>> it, and pretty large OUs, etc.  So why would it be a candidate for
>going
>> into the kernel?  And why is kdbus so important in the kernel as
>well?
>> People have talked about it needing to be there for bootup, but isn't
>that
>> why we ripped out RAID detection and such from the kernel and built
>> initramfs, so that there's LESS in the kernel, and more in an early
>> userspace?  Same idea with dbus in my opinion.
>
>Let me elaborate on the initramfs/shutdown situation a little bit more,
>because I have to deal with that every day.
>
>Because of the "let's move everything to userspace" sentiment we
>nowadays
>have the situation, that we need a lot of tools to setup the root
>device.
>
>Be it LVM on IMSM or iSCSI multipath, the initramfs has to setup the
>network
>(with bridging, bonding, etc.), the iSCSI connection, assemble the
>raid, the
>LVM, open crypto devices, etc...
>And if something goes wrong, you want to have a shell, see all the logs
>and
>debug things.
>
>Now over the time we moved away from simple shell scripts (without any
>logging) and static compiled special versions for the initramfs to a
>mini
>distribution in the initramfs, which simplifies maintenance and
>improves
>reliability.
>
>Basically you want to use the same tools in the initramfs (and
>shutdown)
>which you already have and use in your real root, with the same
>configuration
>files and the same interfaces and the same code paths.
>
>Therefore systemd is started in dracut created initramfs, which starts
>journald for logging. The same basic systemd targets exist in the
>initramfs
>as on the real root, so normally you don't have to cope with
>specialized
>versions for the initramfs.
>
>The target here is to have the same IPC mechanism from the very
>beginning to
>the very end. No crappy fallback mechanisms in case a daemon is not
>running
>or has crashed, no creepy transition from initramfs root to real root
>to
>shutdown root.
>
>We already have such transitions like: systemd, journald, mdmon [1],
>etc.
>systemd has to serialize itself, journald's file descriptors are
>transitioned
>over, mdmon jumps through hoops. Remember you want to get rid of open
>files
>and executables and have to reexec everything, if you transition from
>the
>initramfs root to the real root, and also from the real root to the
>shutdown
>root.
>
>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...
>
>dbus-daemon would have to transition to the real root, and from the
>real root
>to the shutdown root, without losing state.

Which does not sound fundamentally hard.  
Unify the roots, and make /run or wherever the dbus socket lives always available.  As long as your initramfs has the latest versions of software there is no need for any tricky transitions except to upgrade software on a running system.


>Of course this can all be done, but it would involve fallback
>mechanisms,
>which we want to get rid off. 

Only if you design things poorly.

>Hopefully, you don't suggest to merge
>dbus with
>PID 1. Also with a daemon, you will lose the points mentioned in the
>cover mail

I don't see how something that is inappropriate to be in PID 1 is better in PID 0.


>I don't care, if the kdbus speedup is only marginal.
>
>In my ideal world, there is a standard IPC mechanism from the beginning
>to
>the end, which does not rely on any process running (except the kernel)
>and
>which is used by _all_ tools, be it a system daemon providing
>information and
>interfaces about device assembly or network setup tools or end user
>desktop
>processes.

And that is a beautiful dream and an absolutely rubbish way to get there.  If the performance is not top notch everything can not use your beautiful IPC mechanism.    Which means your dream fails.

Good performance is a hard requirement to get where you want to be.

>dbus _is_ such an easy, flexible standard IPC mechanism. Of course, you
>can
>invent the wheel again (NIH, "we know better") and wait and see, if
>that
>works out. Until then the whole common IPC problem is unresolved and
>Linux
>distributions are just a collection of random software with no common
>interoperability and home grown interfaces.


kdbus seems to be the NIH "we know better better" approach.  Many of it's design decisions we have chosen to differently elsewhere in the kernel because the have caused problems.  When these issues have been pointed out in review people have blown off leading to the current mess.

Furthermore I don't know that I have seen people arguing for transporting something other than dbus messages but rather I have seen people pointing out there have been many excellent IPC mechanisms that are simpler and faster for the same kind of task and suggesting mapping dbus to better kernel primitives might be productive.

But seriously if you want to have one IPC mechanism to rule them all you won't succeed in convincing everyone with the currently sloppily designed kdbus code.

Performance matters, simplicity matters, being able to explain design decisions matter.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists