Hi Ahmed, Could you copy that suggestion to the thread here where we're discussing the format for HAL interfaces? https://www.mail-archive.com/[email protected]/msg15150.html That way your suggestion doesn't get lost in this unrelated thread.
Best, Matteo On Tue, Sep 29, 2026 at 12:40 PM Ahmed Ashraf <[email protected]> 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 > > >
