Anchao, I agree with you in the sense that it would be great to have this functionality in NSH. However, we simply don't have that and the contributor who provided the nxinit patch has no interest (from what I can tell) in patching NSH. Two init systems seems like the way to go here, especially because NSH shouldn't be an init system.
I think because it is an app, there is no obligation to support two systems. NSH has been the default for a long time, which is fine, and it can continue to be the default since basically every board has a configuration with it. This nxinit is a nice alternative which the contributor has also documented, so end users can choose to opt out of NSH and use nxinit instead. It won't affect the kernel. If there's a preference not to have kernel configurations that use nxinit, that's another thing. In regards to NSH, I think hopefully the addition of nxinit can push us towards improving it. It really shouldn't be doing OS initialization, and I remember that came as a shock to me when I was starting with NuttX. As much of that as possible should be moved into code that runs after boot (similar to registering devices). Regardless of whether or not we do that, nxinit also is meant to have a smaller footprint from what I understand in the contributor's explanation. Which honestly doesn't surprise me, because it doesn't have a whole shell that comes with it. I also hope the addition of this init system might push us to move the NSH builtin commands to proper apps so they can be used by all systems. Matteo On Tue, Oct 28, 2025, 8:53 AM Alan C. Assis <[email protected]> wrote: > Exactly Matteo! > > In some cases NSH could be harmful: > I remember the example of a drone company that asked us to disable the > memory display and modification commands because someone used these > commands to read their proprietary code that was in a separate partition in > the memory. > > At that time I didn't agree with that, because the NuttX kernel > configuration responsibility should be of the company that develops the > product. But the community agreed with them and now these memory tools are > disabled by default. > > BR, > > Alan > > On Tue, Oct 28, 2025 at 9:39 AM Matteo Golin <[email protected]> > wrote: > > > I don't think anchao formally rejected the PR (i.e. stated rejection), > just > > had a lot of pushback. I think based on the rest of the community's > > response to nxinit, most everyone would like this feature to be merged. > > > > I think these PRs should be reopened so that we have the chance to give > > them approval. If anchao still rejects the PR, that is their right, but > the > > community vote decides if it gets merged or not anyways, not an > individual. > > > > The saying goes "talk is cheap, send patches". A lot of the concern stems > > from having another init system to solve the NSH init coupling to the > > system shell from what I can read. But if people really want a two-stage > > init approach on NSH, they need to send patches. This unit problem has > been > > discussed on NuttX for a long time now and this is the first PR I've seen > > doing anything about it. NSH can be improved later if so desired. Like > > others have mentioned, this is a NuttX app which is completely optional, > no > > one is being forced to use anything. On the contrary, people are forced > > into using NSH for init currently unless they roll their own > > initialization. > > > > Matteo > > > > On Tue, Oct 28, 2025, 8:03 AM raiden00pl <[email protected]> wrote: > > > > > 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. > > > > > > > > > >
