Hello again
Documentation is always a good start, it could have more examples and
current status about actually supported features, and differences with
the android documentation pointed elsewhere.
It is not always fun to dig useful example code in the boards dir,
beginners will hate it and may not even think about that.
Sebastien
On 10/23/25 12:37, Sebastien Lorquet wrote:
Hello
I reviewed your code and I find it very cool.
You did a great job on implementing some quite compact and efficient
code.
I like that you did not try to implement properties that look like the
most complex and probably less usefull stuff of this whole thing. If
you do want to implement properties, please make sure that this part
is entirely optional and the code still can be built without it.
However, this init thing is rather specific for complex systems with
several services. It must absolutely be kept optional and not forced
on small systems.
Documentation of this program is absolutely a requirement to make it
shine to its proper value, I think it is so useful and a nice addition
to NuttX that it must be improved as much as possible so people can
use it easily without struggles.
I actually see myself trying to use this in one of our products. It
solves many use cases we had to deal with, including services with
dependencies, stuff to do after net is initialized, test modes, etc.
I support the inclusion of this app once the naming problems are
addressed. I have no additional added value here, I already made a
proposal of a new top directory in apps to support system
initialization programs, because system/init is a bit too generic.
When I get the occasion I will try to evaluate it and make it work on
a nucleo based stm32h7 board.
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!******/#
