UnderStanding Systemd Part -II

This Post is from my understanding of the original post by leannart poettering on systemd :- 

http://0pointer.de/blog/projects/systemd.html

At this point may be we should look back and analyse how the init scripts work, and have worked over the past so many generations, and may be draw a parallel with kde's style of booting up.

SystemV init ----> Upstart ----> Systemd

SystemV's Approach :-

Finding the dependencies between services and starting them according to a topological sort is inherently serial. You could start daemons that don’t depend on one another at the same time, but if two daemons both depend on dbus, dbus must start first. This creates inevitable bottlenecks which slow down the boot up.

Upstart's Approach :-

“All jobs waiting on a particular event are normally started at the same time when that event occurs”. This means that all services that depend on dbus are started immediately after dbus has finished starting. Although this certainly improves boot times by a fair margin (Ubuntu boots very quickly nowadays), the bottleneck is still there.

Systemd/launchd's Approach :-

What Happens is that for every daemon the resources gets allocated right at the start,(resources here implies, the sockets and the ports), while keeping the mapping from resources to the daemons, it is pretended that everything has been started, while loading all the daemons simultaneously. If a daemon requires a socket that belongs to a daemon that has not finished starting yet, the requests are buffered and ordered by the kernel and the requesting daemon blocks, waiting for an answer. Finally, when a daemon finishes starting up, it gets all the requests buffered by the kernel without any fuss, as if it had just received them.

I am not too sure, but from the look of things, it seems that kde's model of start-up is pretty much similar to either Upstart's or SystemV's approach, starting one process after another serially. Analysing my system boot charts, it looks more close to Upstart's approach. Here the order of execution is :-

KDE Display Manager ----> startkde script ----> (1). kdeinit (starts various services)  ---->  klauncher + kded + kcminit

                                                                              (2). ksmserver

Image Showing System Processes of my system with init script being high-lighted .

To achieve something close to systemd's model, the focus area should be the tie-up between kdeinit script and its subsequent sub-processes, and how we can parallise the process calls instead of the current serial inter-connections, between the processes. Apparently this approach should be highly feasible for an enviro like kde/gnome. But editing and implementing all these scripts is still going to be a Herculean task.