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>
init.rc
on boot && property:sys.boot.reason!=bootloader
echo "On boot, the reason is not BL."
Before fixing
init_main: action 0x40436120
init_main: sys.boot.reason!=bootloader
init_main: argv[0] 'echo'
init_main: argv[1] 'On boot, the reason is not BL.'
After fixing
init_main: action 0x40436120
init_main: sys.boot.reason!=bootloader
+ init_main: default==boot
init_main: argv[0] 'echo'
init_main: argv[1] 'On boot, the reason is not BL.'
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
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>
Add built-in property sys.boot.reason, which allows action triggers to be
executed on specific reset cause.
For example:
```
on property:sys.boot.reason=cpu_soft_reset(bootloader)
echo "bootloader mode ..."
start fastboot
```
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
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>
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>
When ETC_ROMFS is disabled to reduce the bin size, we can provide the init.rc
file via a pseudo-file in the boards/vendor directory. For example:
- CONFIG_ETC_ROMFS=n
- CONFIG_PSEUDOFS_FILE=y
- CONFIG_DISABLE_PSEUDOFS_OPERATIONS=n
```C
FAR const char *init_rc =
"on init\n"
" start console\n";
"service console sh\n"
" restart_period 100\n";
int fd = open("/etc/init.d/init.rc", O_WRONLY | O_CREAT);
/* ... */
ssize_t n = write(fd, init_rc, strlen(init_rc) + 1);
/* ... */
close(fd);
```
The last character '\0' in the file content will be treated as a new line,
and the number of parsed parameters will be zero (abnormal, there should be
at least one keyword).
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Add support for booting a new application firmware image.
Depends on `BOARDCTL_BOOT_IMAGE`.
When the built-in boot command of nsh is enabled, the built-in boot
command of Init will take precedence (see init_builtin_run()). To use
the built-in boot command of nsh, use: `exec -- sh boot [args...]`.
Referred to nshlib/nsh_syscmds.c: cmd_boot()
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
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>
Format: exec_start <service>
Start the specified service and pause the processing of any additional
initialization commands until the service completes its execution. This
command operates similarly to the `exec` command; the key difference is
that it utilizes an existing service definition rather than requiring
the `exec` argument vector.
This feature is particularly intended for use with the `reboot_on_failure`
built-in command to perform all types of essential checks during system boot.
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
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>
wangjianyu3