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
