qemu-armv8a/fastboot: Switch init entry point from NSH to Init #17216
Conversation
Switch the `INIT_ENTRYPOINT` from nsh_main to init_main, and let Init launch the necessary services: console and fastboot. Signed-off-by: wangjianyu3 <[email protected]>
JianyuWang0623
requested review from
jerpelea,
raiden00pl and
simbit18
as code owners
github-actions
bot
added
Board: arm64
Size: S
There was a problem hiding this comment.
Just a feedback after dev@ mailing list discussion, thank you for understanding / considering @JianyuWang0623 :
- We clearly need to use "Android System Init" naming here and update all kconfig/global variables names to clearly distinguish from current NuttX Init, Android System Init, and SystemV Init (there is sill a change it will show up here one day), maybe others. "system_system" or "system_init" or "init_main" is really confusing and not self-explanatory, does not even point to "android_system_init". I know this is a bit longer but will provide important context and clear separation between completely different functionalities / implementations.
- We need better documentation for this "Android System Init" as well as "Fastboot". These functionalities are welcome, people want to use it, but users / developers ask questions like: Why do we need another init system? What should happen with the previous ones? What does this new init system solve? How this relates to Fastboot? When, why, and how can I use it? What are best use cases with some examples? Please consider approach like explaining and convincing someone who wants to use it but has zero knowledge about the solution.
| CONFIG_DRIVERS_VIRTIO_RNG=y | ||
| CONFIG_DRIVERS_VIRTIO_SERIAL=y | ||
| CONFIG_DRIVERS_VIRTIO_SOUND=y | ||
| CONFIG_ETC_ROMFS=y |
There was a problem hiding this comment.
add new config named fastboot_init?
There was a problem hiding this comment.
@anchao Sorry for the overly brief PR title(updated). Fastboot has no direct connection with init. The modification of this PR is to switch the init entry point of the configuration "qemu-armv8a:fastboot" from nsh_main to init_main; For the function of "qemu-armv8a:fastboot", this modification may not be mandatory, and it is more of an example for the newly added Init component(apache/nuttx-apps#3192).
| endif() | ||
|
|
||
| if(CONFIG_FS_ROMFS) | ||
| list(APPEND RCSRCS etc/init.d/init.rc) |
There was a problem hiding this comment.
Separate this commit with defconfig
JianyuWang0623
changed the title
@anchao As the data above , NSH, when used as an initialization program, may seem relatively bloated in scenarios where code size is a major concern. NSH and Init can coexist, allowing users to choose based on their own needs. Init addresses issues such as the excessive code size of NSH when used as an initialization program, and its lack of management (e.g., restarting) for daemons.
For the ELF file, Init requires 61,488 bytes, while NSH and NSH_LIBRARY together require 617,632 bytes. Switching from NSH to Init can save a significant amount of space(556,144 bytes). |
This isn't a fair comparison, and I'm not convinced that nsh could disable more commands to align with init. |
@anchao You're right. When making comparisons, the non-essential functions of NSH should be turned off. A rough estimate shows that after disabling the non-essential functions of NSH (as listed below), the ELF size has decreased by 397,448 bytes. It is estimated that the space required for NSH is approximately 220,184 bytes, and the init component takes up 61,488 bytes. $ diff defconfig boards/arm64/qemu/qemu-armv8a/configs/fastboot/defconfig
9d8
< # CONFIG_NSH_CONSOLE is not set
47c46
< CONFIG_INIT_ENTRYPOINT="nsh_main"
---
> CONFIG_INIT_ENTRYPOINT="init_main"
78,135d76
< CONFIG_NSH_DISABLE_ARP=y
< CONFIG_NSH_DISABLE_BASENAME=y
< CONFIG_NSH_DISABLE_CAT=y
< CONFIG_NSH_DISABLE_CD=y
< CONFIG_NSH_DISABLE_CMP=y
< CONFIG_NSH_DISABLE_CP=y
< CONFIG_NSH_DISABLE_DF=y
< CONFIG_NSH_DISABLE_DIRNAME=y
< CONFIG_NSH_DISABLE_DMESG=y
< CONFIG_NSH_DISABLE_ECHO=y
< CONFIG_NSH_DISABLE_ENV=y
< CONFIG_NSH_DISABLE_ERROR_PRINT=y
< CONFIG_NSH_DISABLE_EXEC=y
< CONFIG_NSH_DISABLE_EXIT=y
< CONFIG_NSH_DISABLE_EXPORT=y
< CONFIG_NSH_DISABLE_EXPR=y
< CONFIG_NSH_DISABLE_FDINFO=y
< CONFIG_NSH_DISABLE_FREE=y
< CONFIG_NSH_DISABLE_GET=y
< CONFIG_NSH_DISABLE_HELP=y
< CONFIG_NSH_DISABLE_HEXDUMP=y
< CONFIG_NSH_DISABLE_IFCONFIG=y
< CONFIG_NSH_DISABLE_IFUPDOWN=y
< CONFIG_NSH_DISABLE_KILL=y
< CONFIG_NSH_DISABLE_LOSETUP=y
< CONFIG_NSH_DISABLE_LS=y
< CONFIG_NSH_DISABLE_MD5=y
< CONFIG_NSH_DISABLE_MKDIR=y
< CONFIG_NSH_DISABLE_MKFATFS=y
< CONFIG_NSH_DISABLE_MKFIFO=y
< CONFIG_NSH_DISABLE_MKRD=y
< CONFIG_NSH_DISABLE_MOUNT=y
< CONFIG_NSH_DISABLE_MV=y
< CONFIG_NSH_DISABLE_NFSMOUNT=y
< CONFIG_NSH_DISABLE_NSLOOKUP=y
< CONFIG_NSH_DISABLE_PIDOF=y
< CONFIG_NSH_DISABLE_PKILL=y
< CONFIG_NSH_DISABLE_PRINTF=y
< CONFIG_NSH_DISABLE_PS=y
< CONFIG_NSH_DISABLE_PUT=y
< CONFIG_NSH_DISABLE_PWD=y
< CONFIG_NSH_DISABLE_RM=y
< CONFIG_NSH_DISABLE_RMDIR=y
< CONFIG_NSH_DISABLE_SET=y
< CONFIG_NSH_DISABLE_SLEEP=y
< CONFIG_NSH_DISABLE_SOURCE=y
< CONFIG_NSH_DISABLE_TEST=y
< CONFIG_NSH_DISABLE_TIME=y
< CONFIG_NSH_DISABLE_TRUNCATE=y
< CONFIG_NSH_DISABLE_UMOUNT=y
< CONFIG_NSH_DISABLE_UNAME=y
< CONFIG_NSH_DISABLE_UNSET=y
< CONFIG_NSH_DISABLE_UPTIME=y
< CONFIG_NSH_DISABLE_USLEEP=y
< CONFIG_NSH_DISABLE_WAIT=y
< CONFIG_NSH_DISABLE_WATCH=y
< CONFIG_NSH_DISABLE_WGET=y
< CONFIG_NSH_DISABLE_XD=y |
|
Okay now I see this update is also a showcase for both Android System Init and Fastboot and this it was created for this reason :-) Lets sort out the naming stuff (gh and dev@) and we will be ready to go :-) Thank you @JianyuWang0623 amazing work :-) |
So nsh still has room for improvement, right? If it's just a size issue, why can't nsh be optimized to support Android init syntax, rather than making a drastic change like replacing the initialization path? My other question is, why is Android's approach the right one? Is it because apple IOS isn't open source? If functionality is aligned with Android, I don't think it's necessary. Each operating system has its own unique characteristics. I like implementations that are superior to Nuttx/Android systems. |
This PR is only dedicated to changing configuration. I think source PR apache/nuttx-apps#3192 would be better place for general discussion about the solution. Best place would be the dev@ mailing list as some folks are not on GH and does not follow specific PRs. Can you please switch to dev@ mailing list so we have better community coverage and awareness? :-) |
@anchao Beyond code size, also take into account the monitoring and management of daemons. As a shell, NSH may already have sufficiently rich functions; however, much of the work in system initialization is irrelevant to the core responsibilities of the shell. Separating and organizing them may make the overall logic clearer. |
So you're also going to provide capabilities similar to Android's Zygote/SystemServer/Firmware Manager, right? So if an app using NSH wants to use these capabilities, it must use Android Init, right? Why this strange design? Is it difficult for NSH to implement these capabilities? |
@anchao The management of daemons/services does not refer to complex functions like Zygote/SystemServer, but rather the status monitoring of daemons such as sh and telnetd. For example, monitoring their exit and then restarting them with a specified interval, configuring the signal sent when stopping the daemons, and determining whether the entire system needs to restart if the daemons encounter exceptions. |
It's more strange to couple the initialization into shell, do you see any other POSIX OS implement in this way? From the concept, init must be one instance and never exit, but shell may be lunched many times(telnet, ssh, adb shell...) or killed. @JianyuWang0623 's work is the right direction to decouple the initialization from nsh from the architecture. But, it's also has other benefit too:
|
|
This is a very good init system, thank you for contributing it. I also see required improvements in nuttx for netinit all our programs have an independent network monitor daemon to manage plug and unplug of cable and manage link up/down and async DHCP and stuff. Having this init system means we can put this net daemon in this init system instead of having weird nsh shell scripts to do it. let' s remember that scripting in nsh is weirdly linked to some automount code that is absolutely not flexible and that we re always patching out to mount our filesystems in our board code. this init system provides a clean solution for all of this, including fs mounts. Has any consensual decision been made on the naming side of things? PS: If you know or guessed who I am please keep it for youself. |
|
@7rx8 Thank you so much for your recognition and valuable feedback. Regarding the naming, we are still coordinating :-) |
5 participants
Summary
Switch the
INIT_ENTRYPOINTfrom nsh_main to init_main, and let Init launch the necessary services: console and fastboot.Related changes:
The impact of Init and NSH on ELF size
Typical scenario: High sensitivity to code size, with no requirement for a shell.
+ETC_ROMFS+INIT-TELENT-NSH_LIBRARY-SYSTEM_NSHFor the ELF file, Init requires 61,488 bytes, while NSH and NSH_LIBRARY together require 617,632 bytes(without non-essential functions: 220,184 bytes). Switching from NSH to Init can save a significant amount of space. (updated)
Depends on apache/nuttx-apps#3192
Impact
Testing
Selftest