Hi All, Thanks for the clarifying messages sent so far. After some internal discussions, we (Espressif) support hosting HAL under github.com/apache (ASF), just as Alin proposed.
Just like Ahmed (mentioned by Matteo) said, this is how Zephyr does it: vendors' HALs are external repositories hosted by Zephyr. Vendors are maintainers along with other community members. The current github.com/espressif/esp-hal-3rdparty/ is already licensed under Apache 2.0, so we could create a PR in its repository hosted by Apache (which would be legally compatible). *The suggestion is to host at repositories like github.com/apache/`nuttx-hal- <http://github.com/apache/`nuttx-hal-><vendor>`*. Another interesting point of view from Ahmed (and, citing Karel as well): NuttX already has an API that separates the driver implementation from its commonly used interface: the lower-half driver. A good example of this is at arch/risc-v/src/common/espressif/esp_rmt.c <https://github.com/apache/nuttx/blob/master/arch/risc-v/src/common/espressif/esp_rmt.c>: its upper-half expects functions to be defined. Those functions were built using Espressif's HAL code, but the upper-half doesn't care about it. To address the concerns about NuttX native vs HAL-based implementations, NuttX can have both: nothing prevents attaching different lower-half drivers to the upper-half. A simple Kconfig option can select which implementation would be used. This allows the community to develop native implementations, while vendors can actively contribute to NuttX. We support vendors willing to contribute to NuttX to follow the same pattern. That being said, *the current `esp-hal-3rdparty` is frozen to enable the transition, depending only on the community's choice*. Its internals will be better explained in its README.md when migration occurs and community contributions will, of course, be very welcome. *We are willing to hear the following discussion and, whenever it's possible (ASAP), create the new repository and start the migration.* Best regards, Em qua., 30 de set. de 2026 às 09:18, Alan C. Assis <[email protected]> escreveu: > Hi Alin, > > If the HAL is provided by an external vendor, the supply chain attack > vector can occur regardless of where we host the code, since the original > code originates from the vendor. > > I think the access to github.com/NuttX is at the same level as > github/apache/nuttx, only NuttX PMCs and committers have write access to > it. > > To host it at ASF, I think we need their agreement to host external code > even when using different licenses (i.e. BSD, MIT, etc) > > BR, > > Alan > > On Wed, Sep 30, 2026 at 5:43 AM Alin Jerpelea <[email protected]> wrote: > > > Hi, > > > > I am concerned about having HALS outside ASF because they can constitute > a > > supply chain attack vector while > > the lack of central user management can create friction between NuttX > > committers and vendor representatives > > > > I propose that we host the HALS under ASF in a separate repository > > nuttx-vendor-hals with same access and rules > > as we have for the whole project. > > > > This ensures that we have proper oversight, access management and > security > > from ASF > > > > Best regards > > Alin > > > > On Tue, Sep 29, 2026 at 10:39 PM Karel Kočí <[email protected]> wrote: > > > > > Hi, > > > > > > I just want to point out that NuttX already has API that does that, > lower > > > and > > > upper drivers. Upper driver is generic, lower is chip specific. API is > > not > > > stable but it is generic. > > > > > > I am still convinced that NuttX should have native chips (without HAL) > in > > > repository and HAL supported chips as external integrations that are > not > > > fully > > > tied to the merge and release cycle of NuttX. I still think that we > > should > > > limit > > > the need of core NuttX developers to understand every single HAL that > > > could be, > > > in some capacity, included and move that to dedicated maintainers > > > (prefferably > > > vendor supplied). That doesn't mean outside NuttX commiters reach, it > > > means that > > > most of the work would be done by dedicated developers with deeper > > > knowledge of > > > external source code (HAL) and not by NuttX developers improving > drivers. > > > Even > > > if HAL supported chips would lag behing NuttX core. > > > > > > With regards > > > Karel > > > > > > > > > On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote: > > > > Hi all, > > > > > > > > I’m relatively new to the discussion, but I was wondering if we could > > > also > > > > consider an approach similar to how Zephyr handles vendor HALs. > > > > > > > > Instead of introducing a universal adapter between NuttX and every > > vendor > > > > HAL, perhaps the boundary could simply be: > > > > > > > > Generic NuttX API > > > > | > > > > NuttX driver > > > > /. \ > > > > native vendor HAL > > > > \ / > > > > hardware > > > > > > > > The driver would integrate only the functionality that NuttX actually > > > needs > > > > from the vendor HAL. For simple peripherals, the driver could use a > > > native > > > > implementation directly, while more complex platforms could reuse the > > > > vendor HAL. > > > > > > > > The vendor HAL itself could remain an external, version-pinned > > dependency > > > > managed by the NuttX build system. > > > > > > > > This seems to avoid the need to implement and maintain a > > general-purpose > > > > adapter for an entire vendor SDK, while still allowing NuttX to > benefit > > > > from existing vendor implementations. > > > > > > > > Zephyr uses a similar principle: vendor HALs can remain external > > modules, > > > > while the Zephyr drivers provide the integration with the generic > > Zephyr > > > > APIs. > > > > > > > > I’m curious what others think about this approach, especially > regarding > > > the > > > > amount of integration and long-term maintenance work compared with > > > > maintaining the HAL under the NuttX umbrella. > > > > > > > > Best regards, > > > > Ahmed > > > > > > > > On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <[email protected]> wrote: > > > > > > > > > On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira > > > > > <[email protected]> wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Following the recent discussion in the thread “Early feedback on > > > RZ/V2H > > > > > > port and RZ FSP HAL dependency”, I would like to suggest applying > > the > > > > > same > > > > > > idea discussed there to existing vendor HAL dependencies: hosting > > > them > > > > > > under github.com/NuttX, while keeping them separate from the ASF > > > > > > repositories. This proposal is aligned with some opinions shared > > > there. > > > > > > > > > > > > A practical example is esp-hal-3rdparty. I recently opened a very > > > small > > > > > fix > > > > > > there: > > > > > > > > > > > > https://github.com/espressif/esp-hal-3rdparty/pull/15 > > > > > > > > > > > > The PR is still open without Espressif review. Interestingly, the > > > > > technical > > > > > > feedback so far came from Laczen, a NuttX contributor who is not > > > part of > > > > > > Espressif. > > > > > > > > > > > > This illustrates the issue when NuttX depends on a vendor > > repository > > > but > > > > > > the vendor is temporarily unavailable to maintain or review it. > > > > > > > > > > > > Would it make sense to move esp-hal-3rdparty, and potentially > > similar > > > > > > vendor HAL repositories, under github.com/NuttX, with vendor > > > maintainers > > > > > > when available but NuttX committers retaining the ability to > review > > > and > > > > > > maintain them when necessary? > > > > > > > > > > > > Best regards, > > > > > > > > > > > > *--Felipe Moura de Oliveira* > > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > > > > > > > > > > I am still opponent of any external HAL/SDK in NuttX, it only > brings > > > > > problems in the long run, but if this particular HAL is already > here > > > > > we may try to experiment with it (and only this one for now) under > > > > > github.com/nuttx umbrella to see if this approach would really > solve > > > > > any problems or add new problems. Time will tell and we can always > > > > > fallback to the current vendor provided and controlled HAL if that > > > > > approach fails for any reason? > > > > > > > > > > -- > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > >
