Okay I have provided feedback from the dev@ list to the gh prs and here comes the reply ;-)
The main advantages of this Android System Init on NuttX: * it is custom trimmed down code implementing android system init compatible functionality. * it can run as standalone app that replaces nsh. * it provides ~10x smaller footprint over nsh. I invited Wang to join discussion here on the mailing list :-) There may be use cases for this. My proposition is to move all Android related stuff to apps/android that is apps/android/system/init and apps/android/fastboot. Also to rename kconfig variables so instead CONFIG_SYSTEM_SYSTEM it will be CONFIG_ANDROID_SYSTEM or similar? What do you think folks? :-) Thanks :-) Tomek On Tue, Oct 21, 2025 at 8:29 AM Luchian Mihai <[email protected]> wrote: > > Hi Tomek, > > I am already more present in the project overall. > I usually leave comments rather than start reviews (regarding PRs). > > There are already comments on Pull Request for the documentation. > This subject that I've raised was more suited for the mailing list. It > reaches more of the community overall. > > More input than mine is needed if we want a resolution. > > Cheers, > Mihai > > On Tue, 21 Oct 2025 at 02:17, Tomek CEDRO <[email protected]> wrote: > > > 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 > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
