They are indeed very similar and both include "rc" (which is probably the
abbreviation for Run Commands?).
BR,
Jianyu Wang
发件人: Alan C. Assis
发送时间: 2025年10月29日 23:00:30
收件人: [email protected]
主题: Re: [External Mail]Re: nxinit integration mess
[外部邮件
_SYSINITSCRIPT="init.d/rc.sysinit"
> CONFIG_NSH_INITSCRIPT="init.d/rcS"
> ```
>
> I will be gladly to submit it to the mainline at the appropriate time.
>
> BR,
> Jianyu Wang
>
>
> 发件人: Alan C. Assis
> 发送时间: 202
me.
BR,
Jianyu Wang
发件人: Alan C. Assis
发送时间: 2025年10月29日 22:06
收件人: [email protected]
主题: [External Mail]Re: nxinit integration mess
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈
Hi Jianyu Wang,
I think using pseudofs is a great idea.
But I suggest using &q
h:
> https://github.com/open-vela/nuttx/pull/266
>
>
> BR,
>
> Jianyu Wang
>
>
> 发件人: Sebastien Lorquet
> 发送时间: 2025年10月29日 0:35
> 收件人: [email protected]
> 主题: [External Mail]Re: nxinit integration mess
>
> [外部邮件] 此邮件来源于小米公
stien Lorquet
发送时间: 2025年10月29日 0:35
收件人: [email protected]
主题: [External Mail]Re: nxinit integration mess
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈
Hi
Next step will be : how to modify these idioms in all the board
make.defs that use romfs?
ifeq ($(CONFIG_ETC_ROM
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, L
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 suppor
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
wrote:
> I haven't had a
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 $(B
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.
C
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 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 elim
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.
+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 wrote:
> +1 for proposed solution
>
> Best regards
> Alin
>
> On Tue, 28 Oct 2025, 15:14 Tomek CEDRO, wrote:
>
> > Good catch Anchao!! We all missed that sorry!! o
+1 as well.
On Tue, Oct 28, 2025 at 10:15 AM Alin Jerpelea wrote:
> +1 for proposed solution
>
> Best regards
> Alin
>
> On Tue, 28 Oct 2025, 15:14 Tomek CEDRO, wrote:
>
> > Good catch Anchao!! We all missed that sorry!! o_O
> >
> > Lets address the issue before merge, so we have better and mor
+1 for proposed solution
Best regards
Alin
On Tue, 28 Oct 2025, 15:14 Tomek CEDRO, 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 nx
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 a
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
On Tue, Oct 28, 2025 at 12:20 PM Michał Łyszczek
wrote:
> On 2025-10-28 11:54:33, Sebastien Lorquet wrote:
> > (..)
> > 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 p
I think people are speculating about why Xiang closed the PR, I think we
need to hear the motives from him.
Maybe it is not related to Anchao comments.
Xiang, could you shed some light on this?
BR,
Alan
On Tue, Oct 28, 2025 at 10:14 AM Matteo Golin
wrote:
> Anchao, I agree with you in the se
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 bec
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 did
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 ex
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 appro
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 nu
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 proj
I would propose a vote from comunity since this is a usefull optional
aplication
Best Regards
Alin
On Tue, 28 Oct 2025, 11:54 Sebastien Lorquet, wrote:
> Hello
>
> It seems that after lots of community integration efforts related to
> this new "nxinit" app user "anchao" has published many conce
Hello
It seems that after lots of community integration efforts related to
this new "nxinit" app user "anchao" has published many concerned
comments about this application.
These comments seem unnecessary negative, as this "nxinit" is just an
app that is entirely optional and breaks nothing,
27 matches
Mail list logo
