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 >
