init issueshttps://gitlab.redox-os.org/redox-os/init/-/issues2019-02-02T18:03:17Zhttps://gitlab.redox-os.org/redox-os/init/-/issues/4Dynamic Dependencies: Event System2019-02-02T18:03:17ZSamwiseFilmoremggmugginsmc@gmail.comDynamic Dependencies: Event SystemAs I mentioned in #3, the current dependency resolution algorithms and surrounding infrastructure are not robust enough to support dynamic addition, deletion, and reincarnation of services. My thoughts are to have some kind of internal e...As I mentioned in #3, the current dependency resolution algorithms and surrounding infrastructure are not robust enough to support dynamic addition, deletion, and reincarnation of services. My thoughts are to have some kind of internal event system, where any threads can post an event with a little data up to a central dispatcher thread, which of course then distributes the required task to another thread. There's a branch up called [event-system](https://gitlab.redox-os.org/redox-os/init/tree/event-system/) where I was experimenting with something like that. However, that attempt was before I had a couple of vital features, like better management of process's environments and a simpler re-implementation of `std::process::Command`. This is pretty much an implementation detail, but one that I don't have a good grasp on, so that's why this is marked as help-wanted.
Some of this also depends on figuring out a better model for dealing with "special" services, like redoxfs and vesad (refer to #3). However, does anybody know of a reasonable simple event bus, or a decent design I could implement that would work well?
This is also a dependency for parallel service startup (really just a means to arrive at parallel startup), although startup times currently are about 2 seconds, so I don't think it's terribly urgent, other than being one of my goals :D.SamwiseFilmoremggmugginsmc@gmail.comSamwiseFilmoremggmugginsmc@gmail.comhttps://gitlab.redox-os.org/redox-os/init/-/issues/3Decide on Immediately Relevant Config Options2019-01-31T04:53:31ZSamwiseFilmoremggmugginsmc@gmail.comDecide on Immediately Relevant Config OptionsService 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 ha...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) to `display:1` (the screen, provided by one of the services on `initfs:/`)
- Parse service files from `file:/` (provided by another service from `initfs:/`, `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:/` provides `file:`, 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/](https://gitlab.redox-os.org/redox-os/init/blob/dependencies/examples/example_service.toml) directory. Hopefully that's helpful.Ship Rewrite as DefaultSamwiseFilmoremggmugginsmc@gmail.comSamwiseFilmoremggmugginsmc@gmail.comhttps://gitlab.redox-os.org/redox-os/init/-/issues/1Better Error Handling2019-01-31T02:23:36ZSamwiseFilmoremggmugginsmc@gmail.comBetter Error HandlingThis issue concerns the rewrite.
Right now the error handling in here is a lot of `failure::Error` and `err_msg`, which results in many situations where error handling could be done better. I don't have a lot of experience working with ...This issue concerns the rewrite.
Right now the error handling in here is a lot of `failure::Error` and `err_msg`, which results in many situations where error handling could be done better. I don't have a lot of experience working with `failure`, so it'll be a learning experience. If anybody wants to help out with this, jump right in.
I'd like to decide on a kind of policy for reporting errors to the user:
1) Spit out errors with the logger right away
2) Try to propagate them up to a fairly central location to be logged
3) Some combination of theseSamwiseFilmoremggmugginsmc@gmail.comSamwiseFilmoremggmugginsmc@gmail.com