17.02.2020, 11:00, "innerspacepilot" <innerspacepilot_at_gmx.com>:
> Just as a thought: You have implemented signal diversion, but limited to
> known signals. Why not just pass unknown signals as numbers or something
> like (S6SIG55011), so they can be diverted by user? You wouldn't have to
> catalogue them.
absolutely right, totally agreed.
i also wondered why he refuses to add this.
just catch and handle ALL possible signals, including the RT signals
and leave it to the user how to react.
> We need good, flexible and user-friendly init alternatives for linux.
right.
>> But even if your containers were using s6, which has a well-defined
>> upstream (me) and which does not understand SIGPWR either, I would not
>> apply your patch suggestion. Why? Because SIGPWR is not standardized,
>> and s6 aims to be portable, it works ootb on other systems than Linux
>> and making it use SIGPWR would endanger that. It's the exact kind of
>> problems you haven't thought of but run into when you want to patch
>> software, and makes patching always more complex than it seems from the
>> outside.
sorry Laurent, this is absolutely ridicolous.
we are talking about using s6 as Linux process #1, so
it should catch, handle and react to all possible signals the
kernel may send to said process, there might be a good reason
for it, same for any other possible platform, be it BSD or SysV unices.
this is inherently unportable per se. there exists no POSIX standard
describing the signals a kernel may send to notify process #1 about
certain events.
Received on Mon Feb 17 2020 - 15:13:39 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC