Dear All,
Thank you, and hello everyone. Please allow me to add some (potentially 
redundant) information as follows:

  1.
Reasons for adding this module: As Tomek helped supplement earlier, the main 
considerations include code size (the shell module is not always required) and 
daemon management (such as status monitoring and restarting of services).
  2.
Reasons for naming it "init": From a functional perspective, this module is 
used for system initialization. Referring to Linux distributions and Android, 
modules with similar functions are generally named "systemd" or "init".
  3.
Regarding NuttX’s support for multiple init entry points: I conducted a simple 
filter using the command find boards/ -name defconfig | xargs grep 
INIT_ENTRYPOINT | cut -d ':' -f 2- | sort -u, and it turns out this is indeed 
the case. However, not all of their logic is used for system initialization. 
For example, CONFIG_INIT_ENTRYPOINT="hello_main" and 
CONFIG_INIT_ENTRYPOINT="ostest_main". The well-known and excellent NSH supports 
almost all system initialization functions; unfortunately, it lacks daemon 
management. Moreover, in scenarios where code size is a critical concern, NSH 
may be somewhat bulky. Therefore, we might need a dedicated module for system 
initialization.
  4.
About the module’s implementation: This module is a new implementation and not 
a port of Android Init. During the development process, I studied the source 
code of the excellent Android Init, but this module is more streamlined and 
compatible with most syntax of the Android Init Language.

Personally, from a functional perspective, I tend to use apps/system/init and 
CONFIG_SYSTEM_INIT. However, if you have more comprehensive considerations, 
options like apps/android/init and CONFIG_ANDROID_INIT are also acceptable to 
me.


Best regards,

Jianyu Wang

________________________________
发件人: Tomek CEDRO <[email protected]>
发送时间: 2025年10月22日 11:37:31
收件人: [email protected]
主题: [External Mail]Re: NuttX and Android System Init

[外部邮件] 此邮件来源于小米公司外部,请谨慎处理。若对邮件安全性存疑,请将邮件转发给[email protected]进行反馈

Okay Jianyu Wang, author of the Android System Init in NuttX code,
joined the dev@ mailing list, welcome, below is the discussion history
as read from the bottom up direction :-)
Tomek

On Tue, Oct 21, 2025 at 11:18 PM Tomek CEDRO <[email protected]> wrote:
>
> Okay I have provided feedback from the dev@ list to the gh prs and
> here comes the reply ;-)
>
> The main advantages of this Android System Init on NuttX:
> * it is custom trimmed down code implementing android system init
> compatible functionality.
> * it can run as standalone app that replaces nsh.
> * it provides ~10x smaller footprint over nsh.
>
> I invited Wang to join discussion here on the mailing list :-)
>
> There may be use cases for this. My proposition is to move all Android
> related stuff to apps/android that is apps/android/system/init and
> apps/android/fastboot. Also to rename kconfig variables so instead
> CONFIG_SYSTEM_SYSTEM it will be CONFIG_ANDROID_SYSTEM or similar? What
> do you think folks? :-)
>
> Thanks :-)
> Tomek
>
>
>
>
>
>
>
>
> On Tue, Oct 21, 2025 at 8:29 AM Luchian Mihai <[email protected]> 
> wrote:
> >
> > Hi Tomek,
> >
> > I am already more present in the project overall.
> > I usually leave comments rather than start reviews (regarding PRs).
> >
> > There are already comments on Pull Request for the documentation.
> > This subject that I've raised was more suited for the mailing list. It
> > reaches more of the community overall.
> >
> > More input than mine is needed if we want a resolution.
> >
> > Cheers,
> > Mihai
> >
> > On Tue, 21 Oct 2025 at 02:17, Tomek CEDRO <[email protected]> wrote:
> >
> > > Yeah, it is good to have a choice, maybe someone will find this
> > > solution useful and better fit for some applications, but.. we can
> > > already see some confusion with all different system / init solutions,
> > > so we should clearly distinguish the naming and functional separation
> > > (system system init does not say anything at all), and better
> > > documentation right from start (like Alan already requested and
> > > Luchian noted).
> > >
> > > Luchian noticed a common but important problem - one person who create
> > > some solution does not create good (or any) documentation right from
> > > start and then anyone who touches the solution needs to reinvent the
> > > wheel, what is tremendous waste of time and resources. I am sometimes
> > > dropped into such rabbit hole in various projects and it takes weeks
> > > or months to understand what is going on :D Good point! Luchian could
> > > you please provide feedback on the Pull Requests too?
> > >
> > > Thanks! :-)
> > > Tomek
> > >
> > >
> > > On Tue, Oct 21, 2025 at 1:00 AM Alan C. Assis <[email protected]> wrote:
> > > >
> > > > Hi Luchian,
> > > > that is what I suggested in the Documentation: before saying what 
> > > > Android
> > > > System Init is, the documentation needs to explain what it is solving on
> > > > NuttX.
> > > >
> > > > More important than that: starts explaining the existing solutions and
> > > when
> > > > to use them.
> > > >
> > > > As Xiang commented in the PR, their initial plan was to implement
> > > SystemV,
> > > > but it was more complex (and probably bigger).
> > > >
> > > > So Android System Init could be more beneficial for someone implemented
> > > > deep embedded system with NuttX.
> > > >
> > > > But I didn't give up trying to get the SystemV Init implementation from
> > > > Google, maybe someone there could help us.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Monday, October 20, 2025, Luchian Mihai <[email protected]>
> > > wrote:
> > > >
> > > > > Hello all,
> > > > >
> > > > > This might stir the waters a bit, but I think it needs to be said.
> > > > >
> > > > > I know Alan already pointed out the need for docs in the PR comments,
> > > but
> > > > > just the documentation is not enough.
> > > > >
> > > > > I think we (the community) or the PMC should be more assertive
> > > regarding
> > > > > these kinds of features.
> > > > > Why do we need another init system? What does this new init system
> > > solve?
> > > > > What should happen with the previous ones?
> > > > > Do not get me wrong, I am not against this new init system, I am in
> > > favour.
> > > > >
> > > > > While NuttX excels in posix compliance as a single standard, a lot of
> > > other
> > > > > things lack unity.
> > > > > Lacking a "default" way of doing things ends up in "hidden features",
> > > or
> > > > > rather, features
> > > > > that are used and known by a set of people.
> > > > >
> > > > > There is also support for fastboot and adb, so the android init system
> > > > > makes sense,
> > > > > but I see nothing that explains why they are present in the first
> > > place.
> > > > > Did they solve something, some time ago? Is the NuttX project aligning
> > > with
> > > > > the android tooling?
> > > > >
> > > > > I would like to point out my experience as a new contributor. It took
> > > me a
> > > > > few months to get the hang of how the thing should be done,
> > > > > or at least what the majority agrees. There are board examples that
> > > differ,
> > > > > but neither are wrong also.
> > > > > The system initialization is the same, I've read documentation about
> > > `exec`
> > > > > and `posix_spawn` and `task_create`,
> > > > > and I am writing docs about the flat, protected, kernel build. Yet, I
> > > still
> > > > > did not find the "NuttX way to leave" the kernel.
> > > > > And here we have another init system.
> > > > >
> > > > > For me this just feels more of a feature creep than a milestone, 
> > > > > sorry.
> > > > >
> > > > > It's hard to market (from my own experience) NuttX as anything other
> > > than
> > > > > "high quality code" if it takes days to
> > > > > figure out the solution (out of the existing few) for a specific
> > > problem.
> > > > >
> > > > > I suggest defining the expectations about this PR, and make a separate
> > > > > documentation page.
> > > > > Is something that NuttX wants to adopt going forward, that is great.
> > > > > Will it help only part of the community, that is also great.
> > > > > The only thing I ask is to make that as obvious as possible, it's
> > > tiring to
> > > > > "unravel the NuttX lore" from the mailing list.
> > > > >
> > > > > Cheers,
> > > > > Mihai
> > > > >
> > > > > On Mon, 20 Oct 2025 at 19:09, Tomek CEDRO <[email protected]> wrote:
> > > > >
> > > > > > well. :-(
> > > > > >
> > > > > > On Mon, Oct 20, 2025 at 3:02 PM Alan C. Assis <[email protected]>
> > > wrote:
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > It is better to use the right naming.
> > > > > > >
> > > > > > > Fitbit implemented support for System V on NuttX and promised to
> > > donate
> > > > > > it,
> > > > > > > but after Google acquired them, none contribution came from them.
> > > > > > >
> > > > > > > Google also used NuttX on ARA Project, but no single code line was
> > > > > > > submitted to the NuttX mainline.
> > > > > > >
> > > > > > > BR,
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > > On Mon, Oct 20, 2025 at 8:07 AM Tomek CEDRO <[email protected]>
> > > wrote:
> > > > > > >
> > > > > > > > Hello world :-)
> > > > > > > >
> > > > > > > > There is a very interesting and useful PR by @JianyuWang0623 
> > > > > > > > that
> > > > > adds
> > > > > > > > support for Android System Init functionality to NuttX [1][2]
> > > with
> > > > > > > > working example on qemu [3]. This is alternative to SystemV Init
> > > and
> > > > > > > > probably other init designs. Please help in reviewing the change
> > > :-)
> > > > > > > >
> > > > > > > > My only concern is naming convention here because just "system"
> > > and
> > > > > > > > "system init" is used (i.e. CONFIG_SYSTEM_INIT,
> > > > > CONFIG_SYSTEM_SYSTEM).
> > > > > > > > This may be a bit confusing because we do not know what init
> > > system
> > > > > > > > standard is used and we silently assume Android. My proposition
> > > is to
> > > > > > > > use "Android System Init" naming convention (i.e.
> > > > > > > > CONFIG_SYSTEM_ANDROID_INIT or something like that), so things 
> > > > > > > > are
> > > > > > > > self-explanatory, and other init systems may be used when
> > > necessary
> > > > > in
> > > > > > > > future without confusion. I am not insisting here and will
> > > follow the
> > > > > > > > community choice.
> > > > > > > >
> > > > > > > > Please let us know what you think :-)
> > > > > > > >
> > > > > > > > Thanks :-)
> > > > > > > > Tomek
> > > > > > > >
> > > > > > > > [1] https://github.com/apache/nuttx-apps/pull/3192
> > > > > > > > [2] https://github.com/apache/nuttx/pull/17215
> > > > > > > > [3] https://github.com/apache/nuttx/pull/17215
> > > > > > > >
> > > > > > > > --
> > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
>
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!******/#

Reply via email to