Hi all, I believe hosting HALs under the Apache umbrella is not viable, and I think we already have a consensus on this. The ideal approach is to host them under github.com/NuttX.
Regarding the vendor's responsibility to maintain the HAL: while vendors can certainly contribute and review code, the community—being the main stakeholder—can and should contribute as well. Finally, there are different roles within our field: some developers focus on applications, others on the kernel, and some on drivers. Since NuttX is a complete RTOS that provides an end-to-end infrastructure, we should encourage and recognize those who add support for new boards. 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 > > > > > > > > > > > -- *--Felipe Moura de Oliveira* Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
