Update on the progress of slew development

["Casper Ti. Vector" <caspervector@gmail.com>]

Since the first announcement [1] of slew [2], a few people expressed
interest in the project, but I have received little feedback regarding
its technical contents.  Therefore although I have successfully deployed
slew on a few real-life systems, it is still quite a slowly moving
personal hobby project.  However, there are a few changes which I think
might be interesting to some people here, which is briefly summarised in
this mail, 5 days before the project's one-year anniversary.

[1] <https://skarnet.org/cgi-bin/archive.cgi?2:mss:1945:201803:pdabbgogplcnfhcmpgkg>.
[2] <https://gitlab.com/CasperVector/slew>.

Previously, slew would only save /run/uncaught-logs/current to
/var/log/init (so rotated log files would be ignored) on shutdown (so
no saved logs if the system crashed).  Now the log-saving mechanism is
implemented in an s6-log rotation processor (`init/save_log.rc'), which
would do the task with best effort (if /var/log/init is unwritable for
too long and the catch-all logger is fed with a large stream, the head
of the stream might be discarded anyway).  The `local' oneshot and
`init/rc.halt' would trigger the mechanism by sending the logger
SIGALRM; currently, the remaining issue is that s6-log would not run
the processor upon SIGALRM if `current' is empty, so a temporary write
failure in /var/log/init plus an unfortunate amount of log (no new bytes
after the rotated and unsaved log) would result in discarded logs.

Other noteworthy changes:
* The issue about slew's fault tolerane mentioned in the original
  announcement has been largely solved.
* "Methods" for polymorphic services are supported: see `lib/fn' and
  `misc/wpa_supplicant/wpa_cli.rc' for an example.
* Information can be passed through the kernel command line to slew: see
  `lib/kcmd.rc', and `init/{load,save}_clock.rc' for an example.

Finally, as some people strongly complained [3] about this issue, I
would like to ask for your opinions about the naming convention: what do
you prefer, more "standardised" names like `wpa_supplicant.wlan0.log' or
easier-to-type names like `wpasup.wlan0.log'?  I can switch to a new
convention if you overwhelmingly support it or if I find a very
convincing argument for it, but I need to be really sure that I would
*not* need to change the convention *more than once*.

[3] <https://forums.gentoo.org/viewtopic-t-1079878-start-25.html>.

Suggestions and questions are welcome.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C