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