2. Dependencies

When services start sequentially, dependencies are implicit in the order of startup. Parallelism benefits from explicit dependencies.

serel allows dependencies to be expressed as:

Examples are shown in Appendix A.

These options offer comparable expressive power to each of the actors with an interest in dependencies: system administrators, OS vendors, and service developers.

Integrity of the dependencies is critical to a healthy boot. serel aggregates dependencies into graphs, which may correspond to a runlevel, a switch between runlevels, or other granularities such as "network" or "windows". Graphs are tested for integrity prior to committing to parallel boot. [1] [2]

It is not assumed that dependencies for all services are known at boot time. Best-effort handling of "unknown" services involves starting such services after all parallel services have finished and retaining the order of startup from the non-serel boot. Other approaches are possible.



Early releases of serel distributed default dependencies by inserting special comments within boot scripts. This approach carries a number of undesirable properties, including the burden of maintaining dependencies scattered across dozens of files. serel now distributes default dependencies in a single xml configuration file.


Apple's OS/X 10 starts it's services in parallel [sv00]. Dependencies are expressed via xml configuration files, one per service.