Re: [GIT PULL] kdbus for 4.1-rc1

[Richard Weinberger]

On Wed, Apr 29, 2015 at 2:47 PM, Harald Hoyer <harald@xxxxxxxxxx> 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.

None of these tools depend on dbus (_desktop_ bus).

> 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...

The only reason why you need dbus in your initramfs is because of systemd
and its tools, isn't it?

> 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.

It depends how you define "beginning". To me an initramfs is a *very* minimal
tool to prepare the rootfs and nothing more (no udev, no systemd, no
"mini distro").
If the initramfs fails to do its job it can print to the console like
the kernel does if it fails
at a very early stage.

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