also -1 for AI conversion. Someone will have to maintain this code later. Contributors come and go, leaving long-term maintainers with the problem.
I really don't like Esperssif's approach to HAL and was one of the first to criticize it. But with the current amount of resources in this project, if Esperssif isn't interested in maintaining AI converted code, I think it's very bad idea. śr., 5 sie 2026 o 18:27 Marco C. <[email protected]> napisał(a): > Let me try to explain the methodology so you can open your mind: > > We would make a single PR. The proof of correctness of this PR is that > **each and every one of our esp32 configurations** we have in the tree > right now will be **bit-identical to their out-of-tree hal counterparts**. > There is no need to review any code (but I would still advocate for human > reviews anyway). I mean bit-identical is letting anyone run bdiff and > verify the final .elf of .bin matches byte-by-byte by themselves. > > This is very different from “let's just rewrite it from scratch based on > the documentation”. Every bug and quirk from the current esp hal will be > present to satisfy the needs of even the most conservative developers. > > This is essentially the same as trimming the dead code of esp32-hal, > figuring out the massive work that is matching the idf kconfigs, and > reformatting the code to match the code style and overall organization to > NuttX standards. > > Nobody, except the maintainers will notice any difference. And for the > maintainers, it will make their life easier because now we will have a > pinned in-tree hal that is ours to maintain and keep up to our standards. > > This is much better than the alternative proposals: > > 1. Wait for espressif to merge our contributions there: it will take a long > time since they affect Zephyr and any other OS and will most probably never > happen. > > 2. Fork the esp hal and maintain it ourselves in a separate repo: which > will not match nuttx coding standards and will diverge from the upstream > hal. And we already need to maintain 2+ repos and we all know the nightmare > of keeping them in sync for cross repo contributions and this will make > things exponentially more complicated. > > 2 would require us to watch the esp hal repo and port the fixes to our > repos, and this will still be required it we go the path of bringing it in > tree. > > So I believe a much better answer than “No” is “if it is inexpensive for AI > to do that, let’s try and open a draft PR, and then we evaluate the results > and the outcome. And then we decide”. > > Open your mind. Peace. > > > Marco Casaroli > > On Wed, Aug 5, 2026 at 17: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 > > > > > > > > > > > > > > > > > > > > > > >
