On Wed, Oct 22, 2025 at 12:26 PM 王健宇 <[email protected]> wrote: > Hi, > > If it's just inspired from android but is an original development, what > > would prevent the use of the "NuttX Init system"? > > The main point discussed here is that Tomek has suggested using the name > "Android System Init".
If you web search "nuttx init" there are already popping up results: [1] https://github.com/apache/nuttx/blob/master/sched/init/nx_start.c [2] https://nuttx.apache.org/docs/latest/applications/nsh/installation.html [3] https://nuttx.apache.org/docs/latest/faq/index.html#how-to-start-directly-my-application-instead-starting-nsh [4] https://www.youtube.com/watch?v=jYvCe8yQ1OY It looks like "init" component is already present in the NuttX. It is the entry point for scheduler [1] that defaults to nsh but can be replaced with any other function via kconfig interface [2][3][4] (CONFIG_INIT_ENTRYPOINT). Adding application named just "init" / "system init" that will be called by existing "init" / "sched init" / "nuttx init" / "system init" is confusing because this name was so far reserved to NuttX functionality and is already associated so. This does not self-explain whether we are talking about "application" init or the "rtos" init. Then, talking about "init script" will not self-explain if we are talking about "nsh init script" or the "application init script compatible with android system init". Alan mentioned interest in yet another SystemV Init. So there may be yet another init possible. This is why I propose to use right from start clear and self-explanatory distinction for the new code proposition to use "Android System Init" in nomenclature, in documentation, in files structure, and in variables structure. This way we will quickly know if we are talking about "NuttX Init" (scheduler) or the "Android System Init" (application) :-) This new functionality also needs good documentation, to explain what it offers (i.e. starting or scheduling other applications), what are benefits (i.e. reduced firmware size), what are implementation limitations (i.e. not fully compatible), and how to use it (i.e. examples). References to this new functionality also should show up in existing documentation places that mention init / initalization (i.e. [2][3]). There will be use cases where this solution is highly desirable and users should find it easily in the documentation in various existing places mentioning system initialization and then go to dedicated detailed description. As this System Init is second application next to Fastboot that comes from Android ecosystem my proposition is to create dedicated apps/android location to keep all Android related components in one place so these are clearly visible and distinguishable from "apps/system" that is "NuttX system" applications. Probably more solutions will show up there. That way user will easily know what Android solutions are ported to NuttX, even if these are minimalistic implementations that provide only selected parts of functionality (that should be clearly documented too). Have a good day folks :-) Tomek ps/2: For some time I am thinking about porting NuttX to Android (using NDK) along with LVGL to see if that can be used as alternative minimalistic and long term self compatible solution to create mobile applications. Parts of this would propably land into rtos/arch and parts in the apps/android. Thus my thoughts here. Its just in my long queue of todo :-P -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
