-1 for HAL approach. It is obvious that this approach is better for vendors, but it is a worse solution for the project: 1. we have to rely on a vendor whose priorities could change at any moment, 2. any HAL updates entail additional workload for maintainers, 3. and probably the most important issue - vulnerability to supply chain attacks.
czw., 24 wrz 2026 o 09:43 Michal Lenc <[email protected]> napisał(a): > > 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 > >>> > >
