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