From: Davin McCall Date: Thu, 5 Dec 2019 13:47:03 +0000 (+1000) Subject: Update TODO, minor updates to COMPARISON/DESIGN X-Git-Tag: v0.8.0~9 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=e9501b1dcf95084d6f7135a9e5c8ec02195968fb;p=oweals%2Fdinit.git Update TODO, minor updates to COMPARISON/DESIGN --- diff --git a/TODO b/TODO index e6cad60..5d6ce98 100644 --- a/TODO +++ b/TODO @@ -1,5 +1,9 @@ For version 0.8.0: ------------------ +* for non-system init, fail if the control socket exists, with option to override this and re- + create the socket instead (as system init does). +* Check that desired_state is getting set correctly. (Currently we don't decide whether a service + will restart until it stops...) * provide a way to check configuration for errors (dinitcheck command) [DONE] * Easy way to reload service description (including if service is running, where possible). * report process launch failure reason (stage & errno) via dinitctl. @@ -13,11 +17,12 @@ For version 0.9.+: * Service description sanity checks: - Service type not specified - maybe default to 'internal' if command not specified - - service command not specified + - if command specified but type not, report an error + - other checks? - errors should also be reported by dinitcheck -For version 1.0: ----------------- +For version 1.0 (i.e. longer-term plans): +----------------------------------------- * Service description parse errors should report line number * dinitcheck should perform lint checks - do named files exist? etc * Limit memory use by control connections. Currently clients can queue commands without limit. @@ -35,8 +40,8 @@ For version 1.0: * Chaining of service process input/output? * Be able to boot and shutdown Linux and FreeBSD (or OpenBSD). -For later: ----------- +For later (post 1.0): +--------------------- * On linux when running with PID != 1, write PID to /proc/sys/kernel/cad_pid so that we still receive SIGINT from ctrl+alt+del (must be done after /proc is mounted, possibly could be left to a service script) diff --git a/doc/COMPARISON b/doc/COMPARISON index e4fd786..f1e708f 100644 --- a/doc/COMPARISON +++ b/doc/COMPARISON @@ -54,6 +54,9 @@ always be useful, and comes at a certain cost of complexity, I argue that it is least sometimes useful, and that the cost is not so high. However, to be fair, many systems have successfully taken the simpler approach. +Now we'll look at some systems which *do* have dependency management: Nosh, OpenRC, +S6-RC, Systemd, and some others. + Nosh suite (http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- @@ -211,11 +214,11 @@ https://github.com/initng/initng. Upstart (Ubuntu; http://upstart.ubuntu.com) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Upstart does not provide real dependency management; instead "events" (including services -starting or stopping) can be specified to trigger start/stop of other services. This is -backwards from the Dinit approach (and that taken by most dependency-managing supervision -systems) which allow the dependencies of a service to be specified declaratively. That is, -if service A depends on service B, Upstart is configured so as to start B whenever A starts -(and it's not possible, or at least not trival, to start A without also starting B). +starting or stopping) can be specified to trigger start/stop of other services. That is, +if service A depends on service B, Upstart is configured so as to start A whenever B starts +(and it's not possible, or at least not trival, to start B without also starting A). +This is backwards from the Dinit approach (and that taken by most dependency-managing supervision +systems) which allow the dependencies of a service to be specified declaratively. Upstart apparently offers a D-Bus interface. Dinit eschews D-Bus in favour of a simple custom control protocol. diff --git a/doc/DESIGN b/doc/DESIGN index 5753e6e..3f00cb0 100644 --- a/doc/DESIGN +++ b/doc/DESIGN @@ -83,7 +83,7 @@ shutdown.cc - shutdown/halt/reboot utility Testing ------- -The tests work by mocking out parts of Dinit, and some system calls, in order to isolate +The unit tests work by mocking out parts of Dinit, and some system calls, in order to isolate functional units. In the src/tests/test-includes directory are three mock headers. When compiling tests, the src/tests/includes directory is populated with (linked) copies of the standard headers from src/include, but with mocked headers taken from src/tests/test-includes instead.