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
