Hi all, after reading both sides I tend to agree with both pros and cons so maybe we can find a middle ground if we host an vendor-HAL repository under NuttX, which is co-maintained by NuttX committers and the vendor representatives - we gain more hands - better integration - ability to share concerns and drive the change - provide guidance and maintain an unified ecosystem for all vendors
This would require that the code is transferred to ASF with a SGA from each vendor and the licenses are granted as Apache 2.0 >From NuttX side - we should be transparent this this is a vendor driven initiative and unmaintained HALS will be marked accordingly - each HAL should have at least 1 assigned vendor maintainer added to a maintainer list for Q&A topics we can not handle Long term we can increase the vendor HAL list and provide better integration with vendor HW since we lack the manpower to port all HW to NuttX while new HW offering grows every year. @Xiang Xiao <[email protected]> I agree that if we want to increase NuttX adoption among industry we should adapt and provide an easy integration option both for vendors and integrators. @Michal I do not consider a problem the vendor leaving the HAL unmaintained since the same may happen with a board ported by a developer which leaves the project and the board is unmaintained. On Thu, Sep 24, 2026 at 10:06 AM Binh Nguyen <[email protected]> wrote: > Hi Michal, > > I agree that relying on a vendor-controlled repository would create this > risk. > > That is why I propose hosting the HAL under the NuttX organization. Both > the vendor's code owners and NuttX committers would have review and merge > rights. > If the vendor stops maintaining the HAL, the NuttX community would still > have the source code and authority to continue maintaining the version used > by NuttX. > > This also allows NuttX-specific fixes to be reviewed and merged without > depending entirely on the vendor's priorities. > I believe this model offers a practical balance between community control > and vendor-supported long-term maintenance. > > Do you think this model could help reduce those risks? > > Best regards, > Binh Nguyen > > On 2026/09/24 07:42:57 Michal Lenc 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 > >
