Hi All, I personally agree with @Alin Jerpelea <[email protected]> approach. Xiang's, Chao An's, Felipe's, Greg's and Binh's points are also valid.
The "under NuttX umbrella" may solve a lot of the existing issues and empower the community while encouraging vendors' contributions. We are considering and studying it. So, for now: +1 Best regards, Em qui., 24 de set. de 2026 às 10:18, Alan C. Assis <[email protected]> escreveu: > 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 > > >>> > > > > >
