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 >
