This seems like a reasonable approach. Our Espressif contributors are
really excellent and submit lots of high quality patches, so they are
definitely an asset. But I do agree about moving to our own governed HAL
over time. I have had this open issue with the Espressif HAL for 3 months
now: https://github.com/apache/nuttx/issues/18805

It is low priority and not very impactful, but it is annoying and I would
like to fix it. Hard to do that if it isn't a high priority on the
Espressif timeline. I think being able to patch things up ourselves would
be a large benefit, and hopefully it doesn't dissuade our excellent
Espressif contributors from continuing to spend their valuable time
maintaining NuttX's support for ESP32!

Matteo

On Wed, Aug 5, 2026 at 8:22 AM Felipe Moura Oliveira <[email protected]>
wrote:

> Good idea Alan! It definitely will help us.
>
>
>
> *--Felipe Moura de Oliveira*
> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> On Wed, 5 Aug 2026 at 09:10 Alan C. Assis <[email protected]> wrote:
>
> > Even although I had worked at Espressif and I am a big fan of their
> > microcontrollers I completely understand the frustrations and issues
> caused
> > by this situation.
> >
> > Suggestion: since we cannot add this external HAL to Apache, we could put
> > it initially in GitHub.com/nuttx and slowly fixing the mainline to avoid
> > depending on this HAL. Hopefully most of the constructions come from
> three
> > Espressif contributors and all these three contributors have committer's
> > write, so they could contribute directly to this HAL.
> >
> > I think this way we can get back the independente of NuttX from its tied
> to
> > the vendor over the time.
> >
> > On Wednesday, August 5, 2026, Michal Lenc <[email protected]> wrote:
> >
> > > Hi,
> > >
> > > unfortunately Espressif HAL has the same issue as most of the company's
> > > (not just Espressif) driven open source projects. It's open source, but
> > you
> > > can't really influence its direction because it's completely under
> > > company's governance and there is no community behind it. I think it
> was
> > a
> > > mistake to let 3rd party HALs into our source code instead of providing
> > the
> > > support ourself - yes, the time investment would be huge and our
> platform
> > > support has its own issues as well, but we sort of opened Pandora's box
> > > with it.
> > >
> > > I agree our long term priority should be to get independent from all
> 3rd
> > > party repositories and projects at kernel level. It's fine for the
> > > applications, but we should have full control of drivers and supported
> > > platforms.
> > >
> > > I would therefore like to ask whether it would be possible to maintain
> a
> > >> fork of esp-hal-3rdparty under the Apache/NuttX umbrella, with
> > appropriate
> > >> NuttX committers having write access.
> > >>
> > >
> > > espressif/esp-hal-3rdparty is under Apache license so I think it should
> > be
> > > possible to fork the repository and maintain it ourself under Apache.
> Not
> > > sure if there are any restrictions on bringing forks to Apache space
> > > though. But this would be a good middle ground between having no
> control
> > > and the need to write the entire platform support from the scratch.
> > >
> > > Michal
> > >
> > > On 8/5/26 02:20, Felipe Moura Oliveira wrote:
> > >
> > >> Hi all,
> > >>
> > >> I would like to raise a concern about NuttX’s dependency on
> Espressif’s
> > >> esp-hal-3rdparty <https://github.com/espressif/esp-hal-3rdparty>
> > >> repository
> > >> and discuss whether there is a way to give the NuttX community more
> > >> control
> > >> over the changes required for its development.
> > >>
> > >> The repository is publicly available, but it is maintained and
> > controlled
> > >> by a single private company. As a result, external contributions are
> > >> handled according to that company’s internal priorities and
> > availability,
> > >> which can make it difficult for the NuttX community to address issues
> > that
> > >> block our own development.
> > >>
> > >> As a concrete example, I opened espressif/esp-hal-3rdparty#13
> > >> <https://github.com/espressif/esp-hal-3rdparty/pull/13>, it has been
> > open
> > >> for 28 days. It is a small change consisting of one commit and 15
> added
> > >> lines across two header files—six lines in one file and nine in the
> > other.
> > >> The PR has been acknowledged, but it has not received a technical
> > review,
> > >> and there is no expected completion date.
> > >>
> > >> I understand that the Espressif maintainers have other priorities, and
> > >> this
> > >> is not intended as criticism of the individuals involved. However, I
> > >> believe it illustrates a governance problem for NuttX: changes
> required
> > to
> > >> support NuttX on specific hardware may depend on a repository whose
> > review
> > >> process and priorities are outside the control of our community.
> > >>
> > >> My experience while porting Dropbear <https://github.com/mkj/dropbear
> >
> > >> was
> > >> quite different. We encountered some problems during the port, but its
> > >> maintainer actively helped by reviewing the code, suggesting changes,
> > and
> > >> quickly accepting the corresponding upstream pull requests.
> > >>
> > >> I would therefore like to ask whether it would be possible to
> maintain a
> > >> fork of esp-hal-3rdparty under the Apache/NuttX umbrella, with
> > appropriate
> > >> NuttX committers having write access. Such a fork could continue
> > tracking
> > >> Espressif’s upstream repository, and generally useful changes could
> > still
> > >> be submitted upstream whenever possible.
> > >>
> > >> If maintaining a repository under Apache is not feasible or
> > >> appropriate, another
> > >> suggestion I have is to start building our own HAL and via kconfig
> > select
> > >> between the internal driver or the 3rd-party. If you have other
> > >> suggestions, please let's talk about them.
> > >>
> > >>
> > >>
> > >> *--Felipe Moura de Oliveira*
> > >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
> > >>
> > >>
> > >
> >
>

Reply via email to