What would worry you specifically?
Are there any assumption of good stability in the board directory layouts?
Like, are users expected to have long term private changes in the board
dirs ?
Instead I see them as examples to be copied and changed by users?
I would just move romfs files to $(BOARD_DIR)/romfs_nxinit
$(BOARD_DIR)/romfs_nshinit instead of having it in $(BOARD_DIR)/src
Naively I do not see any long term maintenance problem here.
I would gladly learn about what I missed.
Sebastien
On 10/28/25 15:45, Tomek CEDRO 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
