I like the idea of tiers. FreeBSD has had tiers for a long time. In FreeBSD, Tier 1 is fully supported, Tier 2 is Developmental, Tier 3 is Experimental, Tier 4 is Unsupported.
We have many architectures and I think it would be a good idea to have a documented system of tiers. This will help document how complete and well-supported an arch is under NuttX. I can't offer input regarding the HAL adapters. It sounds like an interesting idea, but I can't dig deeper into it right now. Thanks, Nathan On Wed, Sep 30, 2026 at 9:25 AM Tiago Medicci Serrano < [email protected]> wrote: > Hi All, > > Thanks for the clarifying messages sent so far. After some internal > discussions, we (Espressif) support hosting HAL under github.com/apache > (ASF), just as Alin proposed. > > Just like Ahmed (mentioned by Matteo) said, this is how Zephyr does it: > vendors' HALs are external repositories hosted by Zephyr. Vendors are > maintainers along with other community members. The current > github.com/espressif/esp-hal-3rdparty/ is already licensed under Apache > 2.0, so we could create a PR in its repository hosted by Apache (which > would be legally compatible). *The suggestion is to host at repositories > like github.com/apache/`nuttx-hal- <http://github.com/apache/nuttx-hal-> > <http://github.com/apache/`nuttx-hal- > <http://github.com/apache/nuttx-hal->><vendor>`*. > > Another interesting point of view from Ahmed (and, citing Karel as well): > NuttX already has an API that separates the driver implementation from its > commonly used interface: the lower-half driver. A good example of this is > at arch/risc-v/src/common/espressif/esp_rmt.c > < > https://github.com/apache/nuttx/blob/master/arch/risc-v/src/common/espressif/esp_rmt.c > >: > its upper-half expects functions to be defined. Those functions were built > using Espressif's HAL code, but the upper-half doesn't care about it. > > To address the concerns about NuttX native vs HAL-based implementations, > NuttX can have both: nothing prevents attaching different lower-half > drivers to the upper-half. A simple Kconfig option can select which > implementation would be used. This allows the community to develop native > implementations, while vendors can actively contribute to NuttX. We support > vendors willing to contribute to NuttX to follow the same pattern. > > That being said, *the current `esp-hal-3rdparty` is frozen to enable the > transition, depending only on the community's choice*. Its internals will > be better explained in its README.md when migration occurs and community > contributions will, of course, be very welcome. > > *We are willing to hear the following discussion and, whenever it's > possible (ASAP), create the new repository and start the migration.* > 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 > > > > > > > > > > > > > > > >
