Decide on Immediately Relevant Config Options
Service configurations currently support cool things like multiple methods, dependencies and provides, environment variables, user and group configuration, and setting redox namespaces. However, there are a couple of corner cases that have proved more difficult for me to fit into the service configuration file model.
Right now, init's flow looks something like this:
- Initialize logger and the state/metadata graph
- Parse service files from
initfs:/
, add them to the graph, and start them all - Switch stdio from
debug:
(kernel provided) todisplay:1
(the screen, provided by one of the services oninitfs:/
) - Parse service files from
file:/
(provided by another service frominitfs:/
,redoxfs
), add them to the graph, and start them all - Drop into the null namespace and
waitpid(0, 0)
I mean, this works really pretty well for the standard setup, but its warrants get less flexible as we go down the list:
- Some service on
initfs:/
providesfile:
, and there are services there which should be started - Some service on
initfs:/
provides 'display:`, and we should switch our output to it - No more services are going to be added during the lifetime of init
- Services do not need to be checked later and reincarnated if they fail
That third one is particularly sticky, and the fourth is directly contradictory to one of the stated goals of this rewrite. Theoretically, one could install a package that provides a service and want to be able to start it after installing it. However, if init is in the null namespace, it is no longer capable of opening files. That's an easy fix, but the dependency and service starting system are also not nearly robust enough to handle dynamically inserted services which must be brought up, nor are they adequate for dealing with a service failure that requires reincarnation. These are all implementation details, and my plan is to implement some kind of event system internally, which should result in a more flexible state/metadata graph.
The reason I opened this issue is to address how to integrate "special" things, like realizing that services in file:/
should be parsed, or that init's stdio streams should be piped to display:1
. I feel like all that stuff should be defined at runtime, but I'm not sure how it fits into the service file model. On this I'd like suggestions. If you'd like to become more familiar with the service configuration file syntax, an example service with many comments can be found in the examples/ directory. Hopefully that's helpful.