Hi Bastian,

2017-01-13 9:28 GMT-08:00 Bastian Bittorf <[email protected]>:
> It is automatically detected if the input is an integer. If not,
> the name is converted to the corresonding number. In general it's
> good style to use names (readability) and it's more portable: signal
> numbers can be architecture-dependent, so we are more safe giving names.
>
> A real world example is signal 10, which is BUS on ramips and USR1 on PPC.

If we know supporting signal number will lead to bug, why not remove it?

My 2 cents
Etienne


>
> Signed-off-by: Bastian Bittorf <[email protected]>
> ---
>
> Changelog:
> v2: give example in decription and safe 1 line of code
>
>  package/system/procd/files/procd.sh | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/package/system/procd/files/procd.sh 
> b/package/system/procd/files/procd.sh
> index 8f18cda..0a441b1 100644
> --- a/package/system/procd/files/procd.sh
> +++ b/package/system/procd/files/procd.sh
> @@ -200,6 +200,7 @@ _procd_add_jail_mount_rw() {
>
>  _procd_set_param() {
>         local type="$1"; shift
> +       local obj old_obj signal
>
>         case "$type" in
>                 env|data|limits)
> @@ -213,9 +214,17 @@ _procd_set_param() {
>                         json_add_string "" "$@"
>                         json_close_array
>                 ;;
> -               nice|reload_signal)
> +               nice)
>                         json_add_int "$type" "$1"
>                 ;;
> +               reload_signal)
> +                       signal="$1"
> +                       test "$signal" -eq "$signal" 2>/dev/null || {
> +                               for obj in $( kill -l ) NOT_FOUND; do test 
> "$signal" = "$obj" && break; old_obj="$obj"; done
> +                               signal="${old_obj%)}"
> +                       }
> +                       json_add_int "$type" "$signal"
> +               ;;
>                 pidfile|user|seccomp|capabilities)
>                         json_add_string "$type" "$1"
>                 ;;
> --
> 1.9.1
>
>
> _______________________________________________
> Lede-dev mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/lede-dev

_______________________________________________
Lede-dev mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/lede-dev

Reply via email to