Hi
Next step will be : how to modify these idioms in all the board
make.defs that use romfs?
ifeq ($(CONFIG_ETC_ROMFS),y)
RCSRCS = etc/init.d/rc.sysinit etc/init.d/rcS
endif
Same with cmake based builds.
The dependency is no longer just on CONFIG_ETC_ROMFS
Sebastien
On 10/28/25 17:24, Luchian Mihai wrote:
Hello all,
I think keeping different names makes sense here.
Using the same file names would lead to overlapping features between
`nxinit` and `nshlib`.
Using both makes sense also, `nxinit` for initialization and daemons and
nsh as interactive shell,
*but* without (some) of the scripting support, the one responsible for
initializing the system.
We can easily avoid that, using Kconfig, keeping a mutual exclusion between
them.
That would result in `nxinit` being coupled to `nshlib`.
I think it is bad overall to couple the apps together, and we should
avoid doing this. I think that
FreeBSD keeps the ports apps completely independent also (maybe I am
wrong?).
So, I would suggest either:
* Keep `nxinit` decoupled from `nshlib`, so separate names.
* We should explicitly state that it is user's responsibility to
not enable both, else both reads the same file, one will fail due to
syntax
Cheers,
Mihai
On Tue, 28 Oct 2025 at 16:57, Alan C. Assis <[email protected]> wrote:
I think having /etc/init.d/nx.sysinit for nxinitand rc.sysinit for nsh init
is nice because we can have both init working.
And also it is intuitive to users/developers to search for init scripts at
/etc/init.d/
BR,
Alan
On Tue, Oct 28, 2025 at 11:53 AM Nathan Hartman <[email protected]>
wrote:
I haven't had a chance to study the proposed solution in depth but I
would
like to say that conceptually I like the idea. If there has been some
friction in the discussions and PR feedback, I hope it can be resolved
amicably :-)
Thanks to everyone for their hard work and valuable contributions.
Cheers,
Nathan
On Tue, Oct 28, 2025 at 10:47 AM Tomek CEDRO <[email protected]> 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
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
