7.4.1 Runlevel assumptions

A runlevel is a system state, i.e. it consists of the information about which services are supposed to be available and which not. This vague definition implies that several different runlevel styles can be implemented in a service manager.

For example, you can do it like System V Init, specifying which services should be started when we enter a runlevel and which ones should be stopped when leaving it. But one could also specify for every service in which runlevels it should be running.

In dmd, we do not want to limit ourselfes to a single runlevel style. We allow for all possible strategies to be implemented, providing the most useful ones as defaults. We also want to make it possible to combine the different styles arbitrariely.

Therefore, when entering a runlevel, we call a user-defined piece of code, passing it the list of currently active services and expecting as the result a list of service symbols which tell us which services we want to have running. This interface makes it very easy to implement runlevel styles, but makes it not-so-easy for the runlevel implementation itself, because we have to get from the current state into a desired state, which might be more or less vague (since it is not required to be a list of canonical names). Obviously service conflicts and already running services need to be taken into account when deciding which services should be used to provide the various symbols.

Also, the runlevel implementation should be implemented completely on top of the service concept, i.e. the service part should not depend on the idea of runlevels or care about them at all. Otherwise understanding the service part (which is the most essential aspect of dmd) would become harder than necessary.