xiaoxiang781216 commented on PR #17216: URL: https://github.com/apache/nuttx/pull/17216#issuecomment-3434948794
> > > So nsh still has room for improvement, right? > > > If it's just a size issue, why can't nsh be optimized to support Android init syntax, rather than making a drastic change like replacing the initialization path? > > > My other question is, why is Android's approach the right one? Is it because apple IOS isn't open source? > > > If functionality is aligned with Android, I don't think it's necessary. Each operating system has its own unique characteristics. I like implementations that are superior to Nuttx/Android systems. > > > > > > @anchao Beyond code size, also take into account the monitoring and management of daemons. As a shell, NSH may already have sufficiently rich functions; however, much of the work in system initialization is irrelevant to the core responsibilities of the shell. Separating and organizing them may make the overall logic clearer. > > So you're also going to provide capabilities similar to Android's Zygote/SystemServer/Firmware Manager, right? So if an app using NSH wants to use these capabilities, it must use Android Init, right? Why this strange design? Is it difficult for NSH to implement these capabilities? It's more strange to couple the initialization into shell, do you see any other POSIX OS implement in this way? From the concept, init must be one instance and never exit, but shell may be lunched many times(telnet, ssh, adb shell...) or killed. @JianyuWang0623 's work is the right direction to decouple the initialization from nsh from the architecture. But, it's also has other benefit too: 1. In many simple case(bootloader, ota), we can enable init, but disable nsh 2. Implement the different init solution -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
