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.
