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