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 > > >
