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 > > > > > > >
