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!******/#
