cederom commented on PR #3192: URL: https://github.com/apache/nuttx-apps/pull/3192#issuecomment-3426667580
> > Just a feedback after dev@ mailing list discussion, thank you for understanding / considering @JianyuWang0623 : > > > > 1. 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. > > 2. 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. > > @cederom The following is part of the reply. > > > Why do we need another init system? What should happen with the previous ones? What does this new init system solve? > > As I supplemented in the data for the PR [apache/nuttx#17216](https://github.com/apache/nuttx/pull/17216) , 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. > Config Changes ELF Size(bytes) > defconfig 7,008,056 > `+ETC_ROMFS` 7,066,048 > `+INIT` 7,127,536 > `-TELENT` 7,127,024 > `-NSH_LIBRARY` > `-SYSTEM_NSH` 6,509,392 > > 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). > > > How this relates to Fastboot? > > Init and Fastboot have nothing to do with each other; it's just that a daemon is needed as an example of a service. > > > When, why, and how can I use it? > > Here are some simple examples: When code size is a major concern and no shell is needed, replacing NSH with Init can save a significant amount of space; management functions such as restarting are required when a daemon fails to start or exits abnormally; and so on. > > > What are best use cases with some examples? > > An example has already been added to [apache/nuttx#17215](https://github.com/apache/nuttx/pull/17215). All this information information would be nice have in the documentation :-) > Some supplementary explanations: > > * The naming "Init" is based on its functional perspective; > > * The Kconfig naming "SYSTEM_INIT" follows the conventions of existing components, with reference to the code path "apps/system/init" where "SYSTEM" corresponds to the "system" directory; > > * Compatibility with Android Init Language is considered for ease of use; > > * However, we are not directly porting Android Init, but rather implementing a new, lightweight Init that is compatible with most of its syntax. I see, then there is nothing blocking the road to name it "Android System Init" right? We could place it in `apps/android/system/init` (maybe just `apps/android/init`) also the fastboot could be moved to `apps/android/fastboot`? Then we have clear separation of functionalities and implementations by name and location. `apps/system` looks more like "NuttX system applications" :-) Anyways we should put this "android" somewhere in the names and paths to clearly distinguish its and implementation coming from Android and not the NuttX internal solution :-) Thanks again @JianyuWang0623 :-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
