Hi, I would like to add one more option to the mix to consider. We could provide a way for NuttX to be more externally extensible and allow manufacturers to integrate their support that way. Right now we allow external board support, but could we also allow external chip support?
Why I am suggesting this? Few reasons: * As stated by multiple people here, code that is under NuttX umbrella is one step, but unification of the interface and coding style between HALs is at that point more important. Having hacks in NuttX code to workaround HAL interface is just stupid. * If we have some HAL repository standards then they will be either compromise that might not help much, or we could just simply integrate them. * There should be clear difference between chips supported and maintained by NuttX and those supported by third-party company. * NuttX should not have to deal with unrelated codebases when doing restructuring outside of stable APIs. Consider change in some driver structure; The author can be expected to update platforms in NuttX, but isn't going to the HALs too much at that point? * That leads to point on manpower. Multiple times in the thread there was statement that we lack the manpower as an argument in favor of HALs, but I think that in long run it will actually drain manpower in form of managing HALs. My opinion is that HAL under NuttX umbrella works only if there are licensing issues that prevents it being licensed under Apache and merged to core NuttX repository. Anything else is compromise that will make maintaining NuttX harder. Thus the idea is to turn table around. If vendor does not want for its reasons to provide "first class" support in the NuttX repository, then it could provide "second class" on top of its HAL or any other implementation it chooses. Burden of supporting this is suddenly on the vendor's side. Karel On Thu 24 Sep 2026 10:18:25 AM , Alin Jerpelea wrote: > 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 > > > >
signature.asc
Description: PGP signature
