Hi Karel, I do not have a clear picture on how different HALs will be maintained by different vendors but at least we will have our community to mediate and provide guidelines.
Regarding the license concern, the vendors can re-license the code to Apache 2.0 or use a double license if it makes sense. I am mostly looking at the Espressif case, which until now seems to be the best option to start such initiative, experiment and build guidelines for other other vendors. Best regards Alin On Wed, Sep 30, 2026 at 11:02 AM Karel Kočí <[email protected]> wrote: > 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 > > > > > > > > >
