When services start sequentially, dependencies are implicit in the order of startup. Parallelism benefits from explicit dependencies.
serel allows dependencies to be expressed as:
xml - serialisation of the W3C's Resource Description Format [wc00]
special comments inside boot scripts, as per the Linux Standard Base Specification [lsb]
synchronisation primitives usable from within boot scripts
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.
| [1] | 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. |
| [2] | Apple's OS/X 10 starts it's services in parallel [sv00]. Dependencies are expressed via xml configuration files, one per service. |