Oopenvela-robotsystem/init: Fix multi-event action triggering
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
system/init: Add setprop support for action Signed-off-by: fangpeina <fangpeina@xiaomi.com> Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add support for action triggers Previously only supported event trigger, now added support for action triggers (property setting). Steps to enable action triggers: - Define all init_property_*() interfaces declared in this file. - Data structures or functions that will likely be used: - struct action_trigger_s - init_action_for_every() Example on boot setprop key_test setprop key_test value_test /* property changed and matched */ trigger event_test on event_test && property:key_test=value_test echo "on event_test, property changed!" on property:key_test=value_test echo "property changed!" Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add system init Refer to the implementation of Android Init Language, consists of five broad classes of statements: Actions, Commands, Services, Options, and Imports. Actions support two types of triggers: event and action. Action triggers also support runtime triggering. Services support lifecycle management, including automatic restart (at specified intervals), and starting/stopping individually or by class. Import supports files or directories, and we may add a static method in the future. The following are some differences: 1. The Android Init Language treats lines starting with # as comments, while we use a preprocessor to handle comments. 2. For action commands, we can omit "exec" and directly execute built-in apps or nsh builtins. 3. Regarding the property service, users can either adapt it by self or directly use the preset NVS-based properties. 4. Only part of standard action commands and service options are implemented currlently. To enable system/init: diff -CONFIG_INIT_ENTRYPOINT="nsh_main" +CONFIG_INIT_ENTRYPOINT="init_main" +CONFIG_SYSTEM_INIT=y For format and additional details, refer to: https://android.googlesource.com/platform/system/core/+/ master/init/README.md Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add setprop support for action Signed-off-by: fangpeina <fangpeina@xiaomi.com> Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Fix multi-event action triggering Action triggered on any event before this fix (e.g. both opposite actions in init.rc below triggered when event "boot" triggered). init.rc on boot && property:sys.boot.reason=bootloader echo "On boot, the reason is BL." on boot && property:sys.boot.reason!=bootloader echo "On boot, the reason is not BL." Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: support compound command execution Example in init.rc: echo "start" && hello && echo "done" ls /missing || echo "not found" echo "A" && echo "B" || echo "fallback" Signed-off-by: fangpeina <fangpeina@xiaomi.com> | 2 个月前 | |
system/init: Add setprop support for action Signed-off-by: fangpeina <fangpeina@xiaomi.com> Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add system init Refer to the implementation of Android Init Language, consists of five broad classes of statements: Actions, Commands, Services, Options, and Imports. Actions support two types of triggers: event and action. Action triggers also support runtime triggering. Services support lifecycle management, including automatic restart (at specified intervals), and starting/stopping individually or by class. Import supports files or directories, and we may add a static method in the future. The following are some differences: 1. The Android Init Language treats lines starting with # as comments, while we use a preprocessor to handle comments. 2. For action commands, we can omit "exec" and directly execute built-in apps or nsh builtins. 3. Regarding the property service, users can either adapt it by self or directly use the preset NVS-based properties. 4. Only part of standard action commands and service options are implemented currlently. To enable system/init: diff -CONFIG_INIT_ENTRYPOINT="nsh_main" +CONFIG_INIT_ENTRYPOINT="init_main" +CONFIG_SYSTEM_INIT=y For format and additional details, refer to: https://android.googlesource.com/platform/system/core/+/ master/init/README.md Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add system init Refer to the implementation of Android Init Language, consists of five broad classes of statements: Actions, Commands, Services, Options, and Imports. Actions support two types of triggers: event and action. Action triggers also support runtime triggering. Services support lifecycle management, including automatic restart (at specified intervals), and starting/stopping individually or by class. Import supports files or directories, and we may add a static method in the future. The following are some differences: 1. The Android Init Language treats lines starting with # as comments, while we use a preprocessor to handle comments. 2. For action commands, we can omit "exec" and directly execute built-in apps or nsh builtins. 3. Regarding the property service, users can either adapt it by self or directly use the preset NVS-based properties. 4. Only part of standard action commands and service options are implemented currlently. To enable system/init: diff -CONFIG_INIT_ENTRYPOINT="nsh_main" +CONFIG_INIT_ENTRYPOINT="init_main" +CONFIG_SYSTEM_INIT=y For format and additional details, refer to: https://android.googlesource.com/platform/system/core/+/ master/init/README.md Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add system init Refer to the implementation of Android Init Language, consists of five broad classes of statements: Actions, Commands, Services, Options, and Imports. Actions support two types of triggers: event and action. Action triggers also support runtime triggering. Services support lifecycle management, including automatic restart (at specified intervals), and starting/stopping individually or by class. Import supports files or directories, and we may add a static method in the future. The following are some differences: 1. The Android Init Language treats lines starting with # as comments, while we use a preprocessor to handle comments. 2. For action commands, we can omit "exec" and directly execute built-in apps or nsh builtins. 3. Regarding the property service, users can either adapt it by self or directly use the preset NVS-based properties. 4. Only part of standard action commands and service options are implemented currlently. To enable system/init: diff -CONFIG_INIT_ENTRYPOINT="nsh_main" +CONFIG_INIT_ENTRYPOINT="init_main" +CONFIG_SYSTEM_INIT=y For format and additional details, refer to: https://android.googlesource.com/platform/system/core/+/ master/init/README.md Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: support compound command execution Example in init.rc: echo "start" && hello && echo "done" ls /missing || echo "not found" echo "A" && echo "B" || echo "fallback" Signed-off-by: fangpeina <fangpeina@xiaomi.com> | 2 个月前 | |
system/init: Add setprop support for action Signed-off-by: fangpeina <fangpeina@xiaomi.com> Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: prevent parser from reading past string boundry Any string ending with whitespace passed to init_parse_arguments() could cause the parser to advance past the string boundary and read unintended memory content. - " echo "A" \0& echo "B" should be parsed as a command with two argvs instand of five. - "command arg " may lead to uncertain results. Signed-off-by: fangpeina <fangpeina@xiaomi.com> | 2 个月前 | |
system/init: Parse default cpu-specific configs On the basis of init.rc, add default parsing of cpu-specific configs. - /etc/init.d/init.rc - /etc/init.d/init.cpu${CPUID}.rc Refactor function init_parse_configs() to parse files from the default path instead of identifying and parsing directories or files, as the functionality is unnecessary. Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add setprop support for action Signed-off-by: fangpeina <fangpeina@xiaomi.com> Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add setprop support for action Signed-off-by: fangpeina <fangpeina@xiaomi.com> Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add reboot_on_failure for service Add support for the reboot_on_failure option to the service. When the execution of a command within a certain action fails (returning a non-zero status code), init will continue to execute subsequent commands or actions and will not proactively terminate the startup process. To implement the functionality of "terminating the startup process after a command execution fails", there are two methods: a. Execute conditional statements (if/then/else/fi) via exec command, but this depends on sh: on init exec -- set +e; \ mount -t fatfs /dev/data /data ; \ if [ $? -ne 0 ] ; \ then \ echo "failed" ; \ reboot ; \ else \ echo "succeed" ; \ fi; b. Via service's oneshot + reboot_on_failure: /* Although the example uses sh, it does not depend on it and can be * replaced with any other Builtin Apps. */ on init exec_start mkdir_tmp ls /tmp service mkdir_tmp sh -c "mkdir /tmp" reboot_on_failure 0 oneshot Test - RC service console sh class core override > reboot_on_failure 0 restart_period 10000 - Runtime [ 0.150000] [ 3] [ 0] init_main: == Dump Services == ... [ 0.170000] [ 3] [ 0] init_main: Service 0x40486ea0 name 'console' path 'sh' [ 0.170000] [ 3] [ 0] init_main: pid: 0 [ 0.170000] [ 3] [ 0] init_main: arguments: [ 0.170000] [ 3] [ 0] init_main: [0] 'service' [ 0.170000] [ 3] [ 0] init_main: [1] 'console' [ 0.170000] [ 3] [ 0] init_main: [2] 'sh' [ 0.170000] [ 3] [ 0] init_main: classes: [ 0.170000] [ 3] [ 0] init_main: 'core' [ 0.170000] [ 3] [ 0] init_main: restart_period: 10000 > [ 0.170000] [ 3] [ 0] init_main: reboot_on_failure: 0 [ 0.170000] [ 3] [ 0] init_main: flags: [ 0.170000] [ 3] [ 0] init_main: 'override' ... [ 0.380000] [ 3] [ 0] init_main: started service 'console' pid 4 ... nsh> kill -9 4 [ 8.060000] [ 3] [ 0] init_main: service 'console' flag 0x20000004 add 0x4 [ 8.060000] [ 3] [ 0] init_main: -flag 'running' [ 8.060000] [ 3] [ 0] init_main: service 'console' flag 0x20000000 add 0x8 [ 8.060000] [ 3] [ 0] init_main: +flag 'restarting' > [ 8.060000] [ 3] [ 0] init_main: Error reboot on failure of service 'console' reason 0 Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 | |
system/init: Add reboot_on_failure for service Add support for the reboot_on_failure option to the service. When the execution of a command within a certain action fails (returning a non-zero status code), init will continue to execute subsequent commands or actions and will not proactively terminate the startup process. To implement the functionality of "terminating the startup process after a command execution fails", there are two methods: a. Execute conditional statements (if/then/else/fi) via exec command, but this depends on sh: on init exec -- set +e; \ mount -t fatfs /dev/data /data ; \ if [ $? -ne 0 ] ; \ then \ echo "failed" ; \ reboot ; \ else \ echo "succeed" ; \ fi; b. Via service's oneshot + reboot_on_failure: /* Although the example uses sh, it does not depend on it and can be * replaced with any other Builtin Apps. */ on init exec_start mkdir_tmp ls /tmp service mkdir_tmp sh -c "mkdir /tmp" reboot_on_failure 0 oneshot Test - RC service console sh class core override > reboot_on_failure 0 restart_period 10000 - Runtime [ 0.150000] [ 3] [ 0] init_main: == Dump Services == ... [ 0.170000] [ 3] [ 0] init_main: Service 0x40486ea0 name 'console' path 'sh' [ 0.170000] [ 3] [ 0] init_main: pid: 0 [ 0.170000] [ 3] [ 0] init_main: arguments: [ 0.170000] [ 3] [ 0] init_main: [0] 'service' [ 0.170000] [ 3] [ 0] init_main: [1] 'console' [ 0.170000] [ 3] [ 0] init_main: [2] 'sh' [ 0.170000] [ 3] [ 0] init_main: classes: [ 0.170000] [ 3] [ 0] init_main: 'core' [ 0.170000] [ 3] [ 0] init_main: restart_period: 10000 > [ 0.170000] [ 3] [ 0] init_main: reboot_on_failure: 0 [ 0.170000] [ 3] [ 0] init_main: flags: [ 0.170000] [ 3] [ 0] init_main: 'override' ... [ 0.380000] [ 3] [ 0] init_main: started service 'console' pid 4 ... nsh> kill -9 4 [ 8.060000] [ 3] [ 0] init_main: service 'console' flag 0x20000004 add 0x4 [ 8.060000] [ 3] [ 0] init_main: -flag 'running' [ 8.060000] [ 3] [ 0] init_main: service 'console' flag 0x20000000 add 0x8 [ 8.060000] [ 3] [ 0] init_main: +flag 'restarting' > [ 8.060000] [ 3] [ 0] init_main: Error reboot on failure of service 'console' reason 0 Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com> | 2 个月前 |