Thanks, that was useful to understand context.

I would avoid strong associations that would imply full compatibility with android. Why not restrict ourselves to suggest this new system is "based" on android stuff, even if for now it is *very* based on it?

It is using the android init language, but it is an independent reimplementation, and we may find interesting additional features not supported by android.


Looking at the pull requests: CONFIG_SYSTEM_INIT kinda implies that this is THE init system.

CONFIG_SYSTEM_AILINIT and CONFIG_SYSTEM_INIT_AIL is a valid value I think (if AIL means android init language).

But we could be a bit more radical here since this is a very specific kind of program.

Could we add a top level "init" directory with your android init in $(APPS)/init/android ?

Would that solve the problem in a good way ?

This leaves room from many other init systems if people want these instead.

NSH is not really an init system, it is a full shell, and yes, it's heavy and init scripting is a bit clunky, with dependencies on automounted romfs and such.


Just one question about this pull request: https://github.com/apache/nuttx/pull/17216

Can this just be a new configuration instead of modification of an existing one? There is no reason to *replace* stuff in existing configs.

eg: leave boards/arm64/qemu/qemu-armv8a/configs/fastboot/defconfig <https://github.com/apache/nuttx/pull/17216/commits/2ba9ce62ecdea6d1501372782cb81798a0743aeb#diff-96078269f3ae76fc83ac8309e6f63c0a4002956cd2a46f4e3ed4f831a8b62c7e> unchanged

and add boards/arm64/qemu/qemu-armv8a/configs/fastboot_android_init/defconfig <https://github.com/apache/nuttx/pull/17216/commits/2ba9ce62ecdea6d1501372782cb81798a0743aeb#diff-96078269f3ae76fc83ac8309e6f63c0a4002956cd2a46f4e3ed4f831a8b62c7e>

What do you think?


Sebastien



On 10/22/25 12:26, 王健宇 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".

Details:https://www.mail-archive.com/[email protected]/msg13694.html

Is there interesting value to keep strict compatibility with "original
android stuff" ?

The main reason is that the Android Init Language has been verified through
long-term practice and has well-established specifications. Compatibility
with this syntax can avoid redundant design and potential pitfalls, thereby
enhancing the stability and reliability of new modules.

Moreover, developers familiar with the Android ecosystem do not need to
learn a new syntax (in fact, I am new to the Android Init Language, but it
is really easy to get started with). This allows them to quickly engage in
development and maintenance work, reducing the learning costs.

Best regards,
Jianyu Wang

________________________________
发件人: Sebastien Lorquet<[email protected]>
发送时间: 2025年10月22日 17:10:02
收件人:[email protected]
主题: Re: 答复: [External Mail]Re: NuttX and Android System Init

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

Hello,

I have well noted that this is fully optional applicative code.

I'll have a look at this when I get some time, because initializing
things is a common problem in embedded systems and an unified way might
be a useful thing.

If it's just inspired from android but is an original development, what
would prevent the use of the "NuttX Init system"?

Inspiration is good, but maybe it's a good occasion to fix flaws you
found in the original android implementation so it becomes even better?

Is there interesting value to keep strict compatibility with "original
android stuff" ?

sebastien


On 10/22/25 11:01, 王健宇 wrote:
Hi,

Thank you for your reminder. Please rest assured—regarding the issue you
mentioned, here is a detailed clarification:

The newly added initialization module is an application program, serving
as an independent and optional feature. Users who need this module can
switch to it by configuring `INIT_ENTRYPOINT`. My previous description may
not have been clear enough, but it was never my intention to replace the
`INIT_ENTRYPOINT` of all boards with `init_main`.

Thank you again for your thoughtful reminder.

Best regards,
Jianyu Wang

________________________________
发件人: Sebastien Lorquet<[email protected]>
发送时间: 2025年10月22日 16:01:45
收件人:[email protected]; 王健宇
主题: Re: 答复: [External Mail]Re: NuttX and Android System Init

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

Hello


Here are some general remarks that may or may not apply ( I did not
check enough), please do not take them personally, they do not apply to
your idea and are just general warnings.


-the boards from nuttx repositories are only samples and are NOT
representative of the usual industrial practice that is applied in
external boards. Please do not make suppositions about proprietary init
systems used by nuttx users.


-the startup of daemons is just ONE of the myriad of possibilities to
init a system. Please make sure that this init system is ONLY an
applicative system that can be entirely be made optional and DO NOT
BREAK existing systems like:

* nsh and its initialization systems

* methods to boot by indicating entry points via names and/or routines.


Again, please, do feature creep as you wish (this is a nuttx philosophy
by now </irony>) but PLEASE do not remove and break existing frameworks
and force everyone to fix their code when updating a release.

Not everyone has hours and days of porting efforts to fix breakage.

NuttX is a mature project and its features are expected to be stable.

Evolution can go forward without being a pain (as much as possible).

Sometimes pain is inevitable, but then negotiation must be made on the
mailing list to manage it beforehand.


Thank you for your attention to every user of nuttx. Use cases are
wildly different and you cannot force every user to follow your shiny
project.

You may not be going in these directions, but some problems like that
happened before, were VERY energy and time consuming to manage so the
project goes back on track, and I do not wish to deal with that sort of
things again.


Sebastien


On 10/22/25 07:07, 王健宇 wrote:
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!******/#
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
 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!******/#
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
 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