Dependency init

[Tristan Wibberley]

Hi,

I've been looking at some of the suggestions and works in progress for
dependency based init, and I'd like to discuss an alternative idea.

The problem with dependency based init is that it's not really
descriptive or flexible enough.

An example feature that I'd like to see in a future Ubuntu release is
that it would be great for gdm to appear *really* early. So that the
username entry box is unavailable, and the same for the face browser and
action menus - but the background appears and you can recognise your
login screen. Then, when a mouse device and keyboard appear, they become
operative. This would make the system feel very snappy on startup. To
acheive sensible behaviour, the gdm startup script would have to get
udev to start instead of depending on it declaratively. In this case, it
might (I don't know) require not insignificant changes to the X server
and gdm to notice and start using the mouse and keyboard.

Similarly for Apache. If the system is booted into a webserver
configuration, it is Apache that is the target service, so that just
gets started, and *it's* startup script tells init that it requires
network interfaces to be brought up. As the interfaces are brought up,
apache is restarted gracefully to start listening on them. Apache (or
it's startup script) would notify init of the interfaces it needs to be
brought up. This would also validate the configuration and present early
feedback - that would give startup a smooth and very professional feel.

Perhaps, though, this is possible in a basic dependency based system
through extra "phantom" services that represent the added features.
Those could depend on the services required for the features they
respectively add as well as depending on the service that will actually
provides them. Such phantom services could then just notify the *real*
service and wait till the real service notifies it that it's now
providing the additional feature, whence it can exit.

This gets really interesting when a service depends on several others
but can do some things as soon as one of those is running (such as the
apache scenario), and even do some things *before* they are running. It
could request the services that add functionality - but still present
the most basic service (or display, or whatever) immediately - including
queuing I/O as early as possible. Programs requesting what they depend
on, instead of init config files *declaring* them is also important for
feature dependencies that can only be determined after processing a
configuration file - which is reasonable to expect. It isn't going to
make sense for some software to have startup scripts for features for
which the requirement to start can only be determined after looking up
in, say, an ldap directory over the network. One very interesting case
is any login service (console or gui) that uses pam. It may be that
postgreSQL, MySQL, or openldap must be started before the login works -
but that is not known until other configuration files are processed -
yet it makes sense for the login program to start up, prompt and wait
for, then accept the username and password before those have started.

How far has work on parallel init progressed in general, and how far
specific to Ubuntu?

-- 
Tristan Wibberley

Opinions expressed are my own and do not necessarily coincide with those
of my employer, etc.