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