Felipe is right, the number of new contributors to NuttX is not very high. NuttX already has many problems, like documentation and being able to maintain stable releases with so few active committers. To be honest, accepting a HAL still seems like a bad idea to me because it's controversial, violates the NuttX principles, and introduces another source of friction for maintaining the RTOS. On the other hand, it is much more practical for the vendor if they are going to commit to maintenance. Hosting it under a NuttX-owned repository is at least much better than cloning an external repository.
I think given how many people are against this idea, we should at least ask Binh Nguyen if Renesas would seriously consider avoiding the HAL route and implementing a NuttX-native port. Binh did reach out for feedback, after all. If that is something Renesas would not be willing to do, then I think we should have a vote about including the HAL under Binh's proposed ownership model. And it might be best to also conduct a vote on this NuttX HAL policy in general to establish some kind of rules if we're going to keep make exceptions (i.e. every proposed HAL inclusion has to undergo a voting process, etc.). The reality is that NuttX is a very under-used RTOS in the market and doesn't have many active maintainers to keep things running as smoothly as other RTOSes. Our documentation is way behind and has been for years. Accepting HALs might increase vendor support and stability, or it might also create more headaches for our limited number of maintainers if Renesas stops maintaining the NuttX-owned HAL. On Thu, Sep 24, 2026 at 10:14 AM Alan C. Assis <[email protected]> wrote: > Hi Tomek, > > Actually it was Li Auto's and Xiaomi's ECUs that brought attention to NuttX > last year :-) > > Re-reading again all sides, I think a middle ground is accepting a HAL, > implemented the same way it is done in Zephyr: under the RTOS umbrella. > > BR, > > Alan > > On Thu, Sep 24, 2026 at 11:05 AM Tomek CEDRO <[email protected]> wrote: > > > On Thu, Sep 24, 2026 at 1:59 PM Tomek CEDRO <[email protected]> wrote: > > > > > > On Wed, Sep 23, 2026 at 8:39 AM Binh Nguyen < > [email protected]> > > wrote: > > > > > > > > Hi all, > > > > > > > > I would like to get some early feedback on the RZ/V2H port. > > > > > > > > We are porting NuttX to the Renesas RZ/V2H Cortex-R8 and currently > > reuse the vendor-maintained FSP HAL for the low-level peripheral drivers. > > > > NuttX still owns the driver interfaces, architecture integration, > > board support, Kconfig and build integration. A thin adaptation layer > > connects the NuttX drivers to the FSP HAL. > > > > > > > > Before we prepare the upstream patches, would using RZ FSP as a > > third-party HAL dependency be acceptable to the NuttX community? > > > > I have also followed the recent esp-hal-3rdparty discussion. I > > understand that external HAL dependencies raise concerns about > governance, > > maintenance and community control, so I would like to clarify the > expected > > approach early. > > > > > > > > FSP HAL is maintained by Renesas, and our team intends to maintain > the > > NuttX RZ/V2H integration and support future FSP updates. > > > > > > > > Would this approach be feasible, and what requirements should we > > satisfy regarding licensing, version pinning, CI and long-term > maintenance? > > > > > > > > Thanks in advance. > > > > Binh Nguyen > > > > Renesas Electronics > > > > > > BIG NO to external vendor HAL, all driver should be in-tree and part > > > of the NuttX RTOS, thank you :-) > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > I am happy to bring Renesas attention to NuttX RTOS. I am not happy > > that I did not get the contract to do the job, that's life. If anyone > > else is about to do the job please please make it right from start. > > Any external HAL only makes things worse in the long run and we avoid > > that in NuttX. Thank you and have fun! :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
