I will be very disappointed if this is the direction that NuttX moves in. The design principles it was built on were great, and the OS is a lot of fun to use, but if we are rewriting major portions with AI I am sad for the future of the project. My vote remains a firm no.
Best, Matteo On Wed, Aug 5, 2026, 11:53 a.m. Alan C. Assis <[email protected]> wrote: > I think we should try. > > In the past the native port was renamed to Legacy and the new HAL approach > became the standard. > > Now we redo it: rename the current HAL to Legacy and the AI conversion > could be tested as a new standard. > > This way those who are against using AI could still use the HAL without any > issue. > > BR, > > Alan > > On Wed, Aug 5, 2026 at 12:44 PM Matteo Golin <[email protected]> > wrote: > > > I strongly oppose this suggestion, so my vote is no. > > > > Matteo > > > > On Wed, Aug 5, 2026, 11:42 a.m. Felipe Moura Oliveira < > [email protected] > > > > > wrote: > > > > > Hi all, > > > > > > Using AI in this situation might not be that bad. It is almost like > > using a > > > translator. We would take what already exists and works, and ask the AI > > to > > > adapt it to our case. > > > > > > For example, we could start with an isolated and simple driver, like > SPI. > > > We could ask the AI to use the 3rd-party HAL as a reference and convert > > it > > > using the standard patterns we already use in stm32. We can approach > this > > > incrementally, one driver at a time. > > > > > > If you agree, I can create a Proof of Concept (PoC) for this. > > > > > > > > > *--Felipe Moura de Oliveira* > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > > > > > > On Wed, 5 Aug 2026 at 12:33 Matteo Golin <[email protected]> > wrote: > > > > > > > The ESP HAL change is a massive undertaking. Having AI relegated to > do > > it > > > > means that we are going to get an even larger increase of AI > generated > > > PRs, > > > > and now ones that entirely compose a very critical layer of a highly > > > > popular vendor device collection on NuttX. Are we going to convince > > > > Espressif developers to help maintain an AI generated copy of their > > HAL? > > > > How are we going to obtain their feedback in the development of a new > > HAL > > > > that lives within NuttX? Which developers are going to have an > > > > understanding of this AI generated HAL? How will it be copyrighted? > How > > > > will we ensure it doesn't violate licensing? > > > > > > > > If we move to a NuttX maintained ESP HAL, which is already a large > ask, > > > it > > > > should be created and maintained by NuttX incrementally to ensure > that > > > it's > > > > stable, license compatible and has some support from our Espressif > > > > contributors who have been maintaining our ESP support so far. AI > > > > generating it in one shot is going to be a huge headache for > > maintainers. > > > > It also, in my opinion, pushes us one step closer to being yet > another > > > slop > > > > project. > > > > > > > > Matteo > > > > > > > > On Wed, Aug 5, 2026, 11:26 a.m. Marco C. <[email protected]> > > > wrote: > > > > > > > > > Can you please elaborate? > > > > > > > > > > > > > > > Marco Casaroli > > > > > > > > > > On Wed, Aug 5, 2026 at 17:23 Matteo Golin <[email protected]> > > > > wrote: > > > > > > > > > > > No. > > > > > > > > > > > > On Wed, Aug 5, 2026, 11:21 a.m. Marco C. < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > Should we AI-convert all espressif HAL into in-tree nuttx? > > > > > > > > > > > > > > It would take a few days, and we can guarantee that the build > are > > > > > > > bit-by-bit matched in day zero, then we would have control of > the > > > > tree > > > > > > and > > > > > > > will need to maintain it. > > > > > > > > > > > > > > Does not sound too bad. > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > Marco Casaroli > > > > > > > > > > > > > > On Wed, Aug 5, 2026 at 17:16 Tomek CEDRO <[email protected]> > > wrote: > > > > > > > > > > > > > > > NuttX by design and by rule uses its own in-tree hardware > > > > > > > > implementation for archs, platforms, mcus, boards, drivers, > > etc, > > > so > > > > > it > > > > > > > > is a self-contained and self-sufficient environment. There > are > > > two > > > > > > > > exceptions to this rule Espressif and RaspberryPi, > > unfortunately. > > > > > > > > > > > > > > > > We are aware of the issue and its pros and cons. There is not > > > much > > > > we > > > > > > > > can do about ESP because of the design of their tools. Yes it > > is > > > a > > > > > > > > moving target.. whoever worked with standalone esp-idf knows > > > that. > > > > > > > > > > > > > > > > Pros: > > > > > > > > + There is a dedicated team in Espressif for NuttX > development > > > that > > > > > > > > maintains the esp-sdk components. > > > > > > > > + We have always up to date implementations and features. > > > > > > > > + Easy migration between different ESP chips inside NuttX > > > > ecosystem. > > > > > > > > + We have new chips support out-of-the-box for free. > > > > > > > > > > > > > > > > Cons: > > > > > > > > - All ESP implementation in NuttX depends completely on > > external > > > > > > > > source that may disappear one day. > > > > > > > > - If we freeze esp-sdk then we loose updates, features, and > > > vendor > > > > > > > > maintenance. > > > > > > > > - We won't be able to cope with amount of changes in esp-sdk > on > > > our > > > > > > own. > > > > > > > > > > > > > > > > This situation is not perfect from NuttX point of view but > > > optimal > > > > > > > > from Espressif point of view, and provides working up-to-date > > > > > > > > environment for NuttX ESP32* users. We have really good > support > > > > from > > > > > > > > Espressif, unlike any other vendor. Any big company has its > > goals > > > > and > > > > > > > > rules that we have no choice to follow, and there are other > > chips > > > > > that > > > > > > > > require some binary blobs too. > > > > > > > > > > > > > > > > I am not sure if we can do anything about it.. unless you > want > > to > > > > > > > > start your own fully open-source esp-sdk? It would be perfect > > to > > > > have > > > > > > > > fully open-source radio stacks but its astronomical amount of > > > work. > > > > > > > > > > > > > > > > The simplest solution to a stalled PR is just asking our > > > community > > > > to > > > > > > > > keep pushing until its processed :-) > > > > > > > > > > > > > > > > -- > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > > > > > > > On Wed, Aug 5, 2026 at 12:21 AM Felipe Moura Oliveira > > > > > > > > <[email protected]> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
