They are indeed very similar and both include "rc" (which is probably the abbreviation for Run Commands?).
BR, Jianyu Wang ________________________________ 发件人: Alan C. Assis <[email protected]> 发送时间: 2025年10月29日 23:00:30 收件人: [email protected] 主题: Re: [External Mail]Re: nxinit integration mess [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 My fault, You are right, "/etc/init.d/init.rc" doesn't conflict with existing names. BR, Alan On Wed, Oct 29, 2025 at 11:49 AM 王健宇 <[email protected]> wrote: > Hi Alan, > > Thank you. If you mean the default path of the NSH script, then there is > no conflict: > ``` > CONFIG_NSH_SYSINITSCRIPT="init.d/rc.sysinit" > CONFIG_NSH_INITSCRIPT="init.d/rcS" > ``` > > I will be gladly to submit it to the mainline at the appropriate time. > > BR, > Jianyu Wang > > ________________________________ > 发件人: Alan C. Assis <[email protected]> > 发送时间: 2025年10月29日 22:06 > 收件人: [email protected] > 主题: [External Mail]Re: nxinit integration mess > > [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 > > Hi Jianyu Wang, > > I think using pseudofs is a great idea. > > But I suggest using "/etc/init.d/nxinit.rc" instead > of "/etc/init.d/init.rc" to avoid collision with "/etc/init.d/init.rc" from > NSH Init. > > BTW, could you please submit this PR to the NuttX mainline? > > BR, > > Alan > > On Wed, Oct 29, 2025 at 10:42 AM 王健宇 <[email protected]> > wrote: > > > Hi, > > > > Regarding the relationship between the init script (such as NSH's rcS or > > others like > > init.rc) and ROMFS, it appears to be a dependency based on the board > code. > > However, > > there are actually other file system (FS) options available—for example, > > pseudofs, > > where we can register a buffer as a pseudo file. The open-vela/nuttx > > repository > > has added new interfaces to simplify usage steps, support write > > operations, and save > > memory. If you are interested, you can refer to this patch: > > https://github.com/open-vela/nuttx/pull/266 > > > > > > BR, > > > > Jianyu Wang > > > > ________________________________ > > 发件人: Sebastien Lorquet <[email protected]> > > 发送时间: 2025年10月29日 0:35 > > 收件人: [email protected] > > 主题: [External Mail]Re: nxinit integration mess > > > > [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 > > > > Hi > > > > Next step will be : how to modify these idioms in all the board > > make.defs that use romfs? > > > > ifeq ($(CONFIG_ETC_ROMFS),y) > > RCSRCS = etc/init.d/rc.sysinit etc/init.d/rcS > > endif > > > > Same with cmake based builds. > > > > The dependency is no longer just on CONFIG_ETC_ROMFS > > > > Sebastien > > > > On 10/28/25 17:24, Luchian Mihai wrote: > > > Hello all, > > > > > > I think keeping different names makes sense here. > > > > > > Using the same file names would lead to overlapping features between > > > `nxinit` and `nshlib`. > > > > > > Using both makes sense also, `nxinit` for initialization and daemons > and > > > nsh as interactive shell, > > > *but* without (some) of the scripting support, the one responsible for > > > initializing the system. > > > > > > We can easily avoid that, using Kconfig, keeping a mutual exclusion > > between > > > them. > > > That would result in `nxinit` being coupled to `nshlib`. > > > I think it is bad overall to couple the apps together, and we should > > > avoid doing this. I think that > > > FreeBSD keeps the ports apps completely independent also (maybe I am > > > wrong?). > > > > > > So, I would suggest either: > > > * Keep `nxinit` decoupled from `nshlib`, so separate names. > > > * We should explicitly state that it is user's responsibility to > > > not enable both, else both reads the same file, one will fail due > to > > > syntax > > > > > > Cheers, > > > Mihai > > > > > > On Tue, 28 Oct 2025 at 16:57, Alan C. Assis <[email protected]> wrote: > > > > > >> I think having /etc/init.d/nx.sysinit for nxinitand rc.sysinit for nsh > > init > > >> is nice because we can have both init working. > > >> > > >> And also it is intuitive to users/developers to search for init > scripts > > at > > >> /etc/init.d/ > > >> > > >> BR, > > >> > > >> Alan > > >> > > >> On Tue, Oct 28, 2025 at 11:53 AM Nathan Hartman < > > [email protected]> > > >> wrote: > > >> > > >>> I haven't had a chance to study the proposed solution in depth but I > > >> would > > >>> like to say that conceptually I like the idea. If there has been some > > >>> friction in the discussions and PR feedback, I hope it can be > resolved > > >>> amicably :-) > > >>> > > >>> Thanks to everyone for their hard work and valuable contributions. > > >>> > > >>> Cheers, > > >>> Nathan > > >>> > > >>> On Tue, Oct 28, 2025 at 10:47 AM Tomek CEDRO <[email protected]> > wrote: > > >>> > > >>>> Yeah that sounds best but how to do this without breaking exiting > > >> stuff? > > >>>> Tomek > > >>>> > > >>>> On Tue, Oct 28, 2025 at 3:28 PM Sebastien Lorquet < > > >> [email protected]> > > >>>> wrote: > > >>>>> My simpler proposal would be to have different romfs directories > for > > >>>>> different init systems, but it is a bit more work. > > >>>>> > > >>>>> Also this would completely eliminate name conflicts. > > >>>>> > > >>>>> But I can live with your proposal, ok. > > >>>>> > > >>>>> Sebastien > > >>>>> > > >>>>> > > >>>>> On 10/28/25 15:25, Alan C. Assis wrote: > > >>>>>> +1 > > >>>>>> I think nx.sysinit and rc.sysinit is a good way to avoid collision > > >> or > > >>>>>> confusion! > > >>>>>> > > >>>>>> > > >>>>>> On Tue, Oct 28, 2025 at 11:16 AM Alin Jerpelea < > [email protected] > > >>>> wrote: > > >>>>>>> +1 for proposed solution > > >>>>>>> > > >>>>>>> Best regards > > >>>>>>> Alin > > >>>>>>> > > >>>>>>> On Tue, 28 Oct 2025, 15:14 Tomek CEDRO, <[email protected]> > wrote: > > >>>>>>> > > >>>>>>>> Good catch Anchao!! We all missed that sorry!! o_O > > >>>>>>>> > > >>>>>>>> Lets address the issue before merge, so we have better and more > > >>>>>>>> coherent solution right from start :-) > > >>>>>>>> > > >>>>>>>> How about /etc/init.d/nx.sysinit for nxinit scripts? So existing > > >>>>>>>> scripts will reside in /etc/init.d/rc.sysinit and there will be > > >> no > > >>>>>>>> conflicts and it will be clear which file is used for what :-) > > >>> Maybe > > >>>> a > > >>>>>>>> selected only file set move to firmware image would be desired > > >> too > > >>>>>>>> based on what init is used? > > >>>>>>>> > > >>>>>>>> You see why I like to bring some attention to dev@ from the GH > > >> PRs > > >>>>>>>> when needed? :-) > > >>>>>>>> > > >>>>>>>> Thank you again!! :-) > > >>>>>>>> Tomek > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Tue, Oct 28, 2025 at 2:55 PM Sebastien Lorquet < > > >>>> [email protected]> > > >>>>>>>> wrote: > > >>>>>>>>> Hello, > > >>>>>>>>> > > >>>>>>>>> I think that the issue that you have identified is very valid > > >> but > > >>> it > > >>>>>>>>> took time for me to identify it. > > >>>>>>>>> > > >>>>>>>>> This is not just a random app used by someone. > > >>>>>>>>> > > >>>>>>>>> This app depends on a set of scripts that reside in the board > > >>>>>>>>> directories, in the romfs directories. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> In fact many boards in the main repo have init files for nsh, > > >> and > > >>>> they > > >>>>>>>>> are set up in a way that was made just for this and is probably > > >>>>>>>>> incompatible with the different requirements of different init > > >>>> systems. > > >>>>>>>>> We need a way to setup several different romfs in board > > >>> directories, > > >>>>>>> one > > >>>>>>>>> would be used for nsh init scripts, the other one with nxinit. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> First of all I want to thank you for identifying this issue > that > > >>>>>>>>> slipped, it is important and must be adressed. > > >>>>>>>>> > > >>>>>>>>> But I do no think that it is blocking integration of the app > > >>> itself. > > >>>>>>>>> I am confident that we can find a good structure for this in > > >> board > > >>>>>>>>> directories. > > >>>>>>>>> > > >>>>>>>>> Writing that from UTC+1, xiao is probably finishing his work > day > > >>>> around > > >>>>>>>>> UTC+7, I hope tomorrow the pull requests will be reopened and > > >> the > > >>>>>>>>> project will go forward. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Sebastien > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On 10/28/25 13:42, chao an wrote: > > >>>>>>>>>> I am not denying nxinit, so I have not added any comments in > > >> the > > >>>> apps > > >>>>>>>>>> repository. All my comments here are about discussing how > > >> nxinit > > >>>>>>>> should be > > >>>>>>>>>> implemented, rather than rejecting the merging of this PR. > > >>>>>>>>>> I don't understand why there was such an intense reaction > > >> during > > >>>> the > > >>>>>>>>>> discussion, even to the extent of closing the PR. > > >>>>>>>>>> nxinit provides system service monitoring capabilities, which > > >>> were > > >>>>>>>> missing > > >>>>>>>>>> from the previous startup scripts. However, I believe we need > > >> to > > >>> be > > >>>>>>>>>> cautious if nxinit is to be integrated into the nuttx kernel, > > >> for > > >>>> the > > >>>>>>>>>> following two reasons: > > >>>>>>>>>> > > >>>>>>>>>> 1. nxinit will cause the system to support two sets of > > >>> script > > >>>>>>>> syntax: > > >>>>>>>>>> android init and nuttx shell. > > >>>>>>>>>> 2. If developers of nsh want to use the service daemon > > >>>>>>> capability, > > >>>>>>>> they > > >>>>>>>>>> need to replace the initialization entry, and the code > > >>>> previously > > >>>>>>>> in the > > >>>>>>>>>> nuttx init script cannot be used continuously. > > >>>>>>>>>> > > >>>>>>>>>> Whether to enhance the existing system implementation or > > >> create a > > >>>> new > > >>>>>>>> set > > >>>>>>>>>> of implementations, the choice is yours. > > >>>>>>>>>> > > >>>>>>>>>> BRs, > > >>>>>>>>>> > > >>>>>>>>>> raiden00pl <[email protected]> 于2025年10月28日周二 20:03写道： > > >>>>>>>>>> > > >>>>>>>>>>> nuttx-apps has always been a collection of useful > applications > > >>> and > > >>>>>>>> libs for > > >>>>>>>>>>> users. Nothing in this repo is mandatory, it's completely > > >>>> optional. > > >>>>>>> I > > >>>>>>>> don't > > >>>>>>>>>>> see > > >>>>>>>>>>> any reason why we should give up from nxinit in nuttx-apps. > > >>> What's > > >>>>>>>> more, I > > >>>>>>>>>>> see > > >>>>>>>>>>> this as a big loss for the project. > > >>>>>>>>>>> > > >>>>>>>>>>> Having a repository like nuttx-apps is a big advantage of > > >> NuttX. > > >>>>>>> This > > >>>>>>>> gives > > >>>>>>>>>>> us more freedom in what we can keep there than if the apps > > >> were > > >>>> part > > >>>>>>>> of > > >>>>>>>>>>> the nuttx kernel repo. So we don't have to look for a perfect > > >>>>>>>> solution, > > >>>>>>>>>>> which probably doesn't exist anyway. > > >>>>>>>>>>> > > >>>>>>>>>>> wt., 28 paź 2025 o 12:20 Michał Łyszczek < > > >>> [email protected] > > >>>>>>>>>>> napisał(a): > > >>>>>>>>>>> > > >>>>>>>>>>>> On 2025-10-28 11:54:33, Sebastien Lorquet wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>>> The nuttx-apps directory already contains many apps whose > > >>> value > > >>>> is > > >>>>>>>> much > > >>>>>>>>>>>> more > > >>>>>>>>>>>>> dubious/discussable than this nxinit thing. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Following these events Xiao Xiang got understandably fed up > > >>> and > > >>>>>>> has > > >>>>>>>>>>>>> retracted all pull requests related to this project. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> I wonder what is the opinion of the community about this > > >>> issue. > > >>>>>>>>>>>>> Should we vote about the integration of this new app? > > >>>>>>>>>>>> I'd say nuttx-apps should be treated like package/ dir in > > >>>>>>> buildroot. > > >>>>>>>> You > > >>>>>>>>>>>> want an app that is useful to you? You just prepare make > file > > >>> and > > >>>>>>>> kconfig > > >>>>>>>>>>>> to > > >>>>>>>>>>>> integrate it and push it. If code is not in nuttx repo, that > > >> is > > >>>>>>>> Makefile > > >>>>>>>>>>>> just downloads .tar.gz from the net and unpacks it - it > > >> doesn't > > >>>>>>> even > > >>>>>>>> have > > >>>>>>>>>>>> to > > >>>>>>>>>>>> follow nuttx code convention. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I myself have added few apps like that. App only contains > > >>>> Makefile > > >>>>>>>> and > > >>>>>>>>>>>> Kconfig > > >>>>>>>>>>>> and code is downloaded from the internet. There was never > any > > >>>>>>> problem > > >>>>>>>>>>> with > > >>>>>>>>>>>> pushing such apps. And I believe I am the only person that > > >> uses > > >>>>>>> them > > >>>>>>>> :) > > >>>>>>>>>>>> So in my opinion, that nxinit should be totally allowed to > be > > >>>> added > > >>>>>>>> to > > >>>>>>>>>>>> apps. > > >>>>>>>>>>>> It's useful to someone. It's 100% optional. It's not > default. > > >>> It > > >>>>>>>> does not > > >>>>>>>>>>>> break > > >>>>>>>>>>>> anything. Hence it should be added without any votes as long > > >> as > > >>>> it > > >>>>>>>>>>> follows > > >>>>>>>>>>>> the > > >>>>>>>>>>>> rules. Even if such app benefits only a single person. > > >>>>>>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> 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!******/#
