I have a different opinion here, how to integrate with the chip specific code it's better to decide by the chip vendor or maintainer. Chip vendors need to support multiple RTOS, it's hard to require them to rewrite all drivers from scratch for multiple RTOS and keep the high quality of evolution. BTW, the community already allows Espressif and Realtek to implement the port on top of their HAL, why do you forbid other chip vendors to do the same thing? It's unfaired and will make more and more chip vendors leave NuttX and enter the Zephyr community. This is an important decision which will impact the NuttX ecosystem deeply in the long term, so it's better to do some balance between the perfect world and the engineering practice.
Thanks Xiang On Thu, Sep 24, 2026 at 10:22 AM Matteo Golin <[email protected]> wrote: > No, in my opinion the only thing that would address the concerns is not > using the HAL and instead providing a native implementation. That's the > NuttX take on the problem, and the HALs that have made it (like the > Espressif HAL) is still controversial. It's best to avoid it entirely. > > Matteo > > On Wed, Sep 23, 2026, 9:57 p.m. Binh Nguyen <[email protected]> > wrote: > > > Hi Alan, Matteo, > > > > Thanks for the feedback. I understand the concern about introducing > > another external HAL dependency. > > > > For Renesas, reusing the FSP HAL is part of our long-term support > > strategy. The goal is not only to reduce the initial development effort, > > but also to keep the low-level drivers aligned with vendor fixes, new > > device support and future FSP releases. Maintaining a separate native > NuttX > > implementation would duplicate the drivers and require an independent > > long-term maintenance effort. > > > > Would a Zephyr-like repository model be more acceptable? > > > > The idea would be to host the HAL repository under the NuttX organization > > as the single source of truth, not as a downstream fork: > > > > - Anyone can contribute through pull requests. > > - The HAL's code owners maintain the HAL, review changes and synchronize > > upstream updates. > > - NuttX committers review the NuttX integration code. > > - HAL repository changes require approval from the code owners. > > - Merge rights, CODEOWNERS, CI and branch-protection rules are > documented. > > > > This would give NuttX more governance over the dependency while keeping > > the HAL aligned with the vendor-supported FSP implementation. > > > > Would this model address the main concerns? If not, what additional > > conditions would be required for it to be feasible? > > > > Best Regards, > > Binh Nguyen > > >
