Hi all, I would like to share my opinion, but first I need to clarify something. Regarding the discussion I started a few months ago about esp-hal-3rdparty, my objection and the approach I tried to take was to continue using the 3rd-party HAL, but keep it under the NuttX umbrella.
For this case, I agree with using a vendor HAL, provided it stays under the NuttX umbrella. This allows us to bring in improvements and updates from the vendor, while also adding or modifying parts ourselves as needed. We can eventually submit PRs from our fork back to the vendor's repository to keep them aligned, without being dependent on them. Best regards, Em qui., 24 de set. de 2026 às 05:50, Michal Lenc <[email protected]> escreveu: > > @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. > > That's true, though it's easier to fix some bug in the code written > directly for NuttX than in 3rd party HAL, even if you didn't used that > MCU before. I can relatively easily look into other MCUs code in NuttX > codebase and add a new feature or fix a bug, I don't think I can do it > in 3rd party HAL. At least not without bigger time investment. > > But hosting HALs under NuttX/ASF as you and Binh Nguyen propose could be > a good middle ground. This repository can follow some common rules so > different HALs wouldn't be completely different and we would have some > control over it. > > Michal > > On 9/24/26 10:18, 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 > >> > > -- *--Felipe Moura de Oliveira* Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
