Hi, wouldn't there be a possibly issue of licenses? Is it enough for ASF hosting if license is Apache compatible? I might have missed info about that in previous mails.
On topic of supply chain attacks. That is always issue when code is provided from outside and when it doesn't match the coding standards of core project. That is one of the reasons why I am insisting on having chips supported by HALs on different documented tier compared to the native ones. But we probably do not have to essentially move HALs them self. It should be enough to have verifiable way to get pinned version of HAL. That would be what nuttx-vendor-hals would be? Or what is your idea behind it? Best regards Karel On Wed 30 Sep 2026 10:42:32 AM , Alin Jerpelea 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 > > > > > >
signature.asc
Description: PGP signature
