Yeah, it is good to have a choice, maybe someone will find this solution useful and better fit for some applications, but.. we can already see some confusion with all different system / init solutions, so we should clearly distinguish the naming and functional separation (system system init does not say anything at all), and better documentation right from start (like Alan already requested and Luchian noted).
Luchian noticed a common but important problem - one person who create some solution does not create good (or any) documentation right from start and then anyone who touches the solution needs to reinvent the wheel, what is tremendous waste of time and resources. I am sometimes dropped into such rabbit hole in various projects and it takes weeks or months to understand what is going on :D Good point! Luchian could you please provide feedback on the Pull Requests too? Thanks! :-) Tomek On Tue, Oct 21, 2025 at 1:00 AM Alan C. Assis <[email protected]> wrote: > > Hi Luchian, > that is what I suggested in the Documentation: before saying what Android > System Init is, the documentation needs to explain what it is solving on > NuttX. > > More important than that: starts explaining the existing solutions and when > to use them. > > As Xiang commented in the PR, their initial plan was to implement SystemV, > but it was more complex (and probably bigger). > > So Android System Init could be more beneficial for someone implemented > deep embedded system with NuttX. > > But I didn't give up trying to get the SystemV Init implementation from > Google, maybe someone there could help us. > > BR, > > Alan > > On Monday, October 20, 2025, Luchian Mihai <[email protected]> wrote: > > > Hello all, > > > > This might stir the waters a bit, but I think it needs to be said. > > > > I know Alan already pointed out the need for docs in the PR comments, but > > just the documentation is not enough. > > > > I think we (the community) or the PMC should be more assertive regarding > > these kinds of features. > > Why do we need another init system? What does this new init system solve? > > What should happen with the previous ones? > > Do not get me wrong, I am not against this new init system, I am in favour. > > > > While NuttX excels in posix compliance as a single standard, a lot of other > > things lack unity. > > Lacking a "default" way of doing things ends up in "hidden features", or > > rather, features > > that are used and known by a set of people. > > > > There is also support for fastboot and adb, so the android init system > > makes sense, > > but I see nothing that explains why they are present in the first place. > > Did they solve something, some time ago? Is the NuttX project aligning with > > the android tooling? > > > > I would like to point out my experience as a new contributor. It took me a > > few months to get the hang of how the thing should be done, > > or at least what the majority agrees. There are board examples that differ, > > but neither are wrong also. > > The system initialization is the same, I've read documentation about `exec` > > and `posix_spawn` and `task_create`, > > and I am writing docs about the flat, protected, kernel build. Yet, I still > > did not find the "NuttX way to leave" the kernel. > > And here we have another init system. > > > > For me this just feels more of a feature creep than a milestone, sorry. > > > > It's hard to market (from my own experience) NuttX as anything other than > > "high quality code" if it takes days to > > figure out the solution (out of the existing few) for a specific problem. > > > > I suggest defining the expectations about this PR, and make a separate > > documentation page. > > Is something that NuttX wants to adopt going forward, that is great. > > Will it help only part of the community, that is also great. > > The only thing I ask is to make that as obvious as possible, it's tiring to > > "unravel the NuttX lore" from the mailing list. > > > > Cheers, > > Mihai > > > > On Mon, 20 Oct 2025 at 19:09, Tomek CEDRO <[email protected]> wrote: > > > > > well. :-( > > > > > > On Mon, Oct 20, 2025 at 3:02 PM Alan C. Assis <[email protected]> wrote: > > > > > > > > +1 > > > > > > > > It is better to use the right naming. > > > > > > > > Fitbit implemented support for System V on NuttX and promised to donate > > > it, > > > > but after Google acquired them, none contribution came from them. > > > > > > > > Google also used NuttX on ARA Project, but no single code line was > > > > submitted to the NuttX mainline. > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Mon, Oct 20, 2025 at 8:07 AM Tomek CEDRO <[email protected]> wrote: > > > > > > > > > Hello world :-) > > > > > > > > > > There is a very interesting and useful PR by @JianyuWang0623 that > > adds > > > > > support for Android System Init functionality to NuttX [1][2] with > > > > > working example on qemu [3]. This is alternative to SystemV Init and > > > > > probably other init designs. Please help in reviewing the change :-) > > > > > > > > > > My only concern is naming convention here because just "system" and > > > > > "system init" is used (i.e. CONFIG_SYSTEM_INIT, > > CONFIG_SYSTEM_SYSTEM). > > > > > This may be a bit confusing because we do not know what init system > > > > > standard is used and we silently assume Android. My proposition is to > > > > > use "Android System Init" naming convention (i.e. > > > > > CONFIG_SYSTEM_ANDROID_INIT or something like that), so things are > > > > > self-explanatory, and other init systems may be used when necessary > > in > > > > > future without confusion. I am not insisting here and will follow the > > > > > community choice. > > > > > > > > > > Please let us know what you think :-) > > > > > > > > > > Thanks :-) > > > > > Tomek > > > > > > > > > > [1] https://github.com/apache/nuttx-apps/pull/3192 > > > > > [2] https://github.com/apache/nuttx/pull/17215 > > > > > [3] https://github.com/apache/nuttx/pull/17215 > > > > > > > > > > -- > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > > > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
