Yeah, if someone really wants to play that way I would suggest aI_* or exp_* nomenclature, and aside to existing stuff, but leave working stuff as is and give people choice on what they want to use.
That was quick to go from "hey my PR is stalled" to "lets rewrite whole esp-sdk with ai and make it default now" :D Maybe it is a good moment to start alternative project like NuttXAI and play over there? We barely cope with basic tasks to maintain project as is. Do you see similarities to "lets rewrite everything in place with Rust" ? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Wed, Aug 5, 2026 at 3:58 PM Matteo Golin <[email protected]> wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
