oops, it should be: "If the project is going to accept HAL we need a separate HAL repository to add all HALs from external vendors."
BR, Alan On Thu, Sep 24, 2026 at 10:18 AM Alan C. Assis <[email protected]> wrote: > Exactly, Michal. > > Another point is that FSP is not really a HAL; it's deeply integrated with > the IDE and wasn't built with a HAL structure in mind. > > Even some people inside Renesas hate it. > > Xiang, if the project is not to accept HAL we need a separate HAL > repository to add all HALs from external vendors. > > Another option is to convert existing HAL based ports to native ports. To > avoid the exception you just commented. > > BR, > > Alan > > On Thu, Sep 24, 2026 at 4:43 AM Michal Lenc <[email protected]> wrote: > >> > 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. >> >> But that would mean we need to rely on chip vendors to keep maintaining >> the project. What if the company decides to abandon the HAL and focus on >> different projects/priorities? This happened many times in the past and >> will happen in the future, company's priorities and goals can change >> over time. The maintenance will then remain on us, NuttX developers, and >> we can't maintain the MCU if it's not even in our codebase. >> >> Or what if we need some changes in HAL because of NuttX codebase, but >> these changes will be rejected because the company wants to go in a >> different direction with the code. There are multiple possible issues >> with it and we are such strong project to be able to dictate the way how >> the HAL should be implemented. >> >> > 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? >> >> And imho it was a mistake we allowed it and there is no reason to repeat >> it. I understand the company's perspective, it even benefits NuttX in a >> short term, we get support for new chips faster and easier after all, >> but managing multiple HALs is a nightmare in a long term. Even now >> fixing bugs in Espressif HAL is a longer process than it would take if >> everything would be in NuttX core repository. >> >> Michal >> >> On 9/24/26 04:43, Xiang Xiao wrote: >> > 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 >> >>> >> >>
