> 1) Espressif always said it would conform to community rules; hence, why we > have been absent. The community must decide first, and then we can see > whether the contribution is feasible.
I think Espressif has at least done very well in engaging with the community. As I mentioned, you are responsive to raised issues even if recently there have been other things taking your time instead of patching them. > 2) We do not block contributions, and we never saw ourselves as 'owning' > Espressif support in NuttX. We do have opinions, and we do try to optimize, > and we do listen to others. We actually expect more people willing to help. Thank you, Tiago! I wouldn't say you 'own' it, but you are in our CODEOWNERS for all the Espressif devices because your reviews and understanding are invaluable for us merging patches. I think that you guys have done an excellent job with it, I don't think I've ever had to request changes on patches from the Espressif team. > Espressif already maintains the HAL of Zephyr (inside Zephyr repo), which > is completely different from that esp-hal used by NuttX. Alan, I had no idea! I thought the Zephyr HAL was also built on top the same ESP HAL we're using. If this is true, then maybe with Tiago's internal escalation Espressif might be willing to help us maintain our own HAL? Best, Matteo > Hi, > > I won't justify HAL, pros, cons, and such. I escalated this internally, and > I have some answers: > > 1) Espressif always said it would conform to community rules; hence, why we > have been absent. The community must decide first, and then we can see > whether the contribution is feasible. > 2) We do not block contributions, and we never saw ourselves as 'owning' > Espressif support in NuttX. We do have opinions, and we do try to optimize, > and we do listen to others. We actually expect more people willing to help. > 3) So far, the discussed options were: > > - Total AI rewrite (I assume at the register level). > - Fork, taking it from there - maybe going Zephyr style. > - Replacing HAL slowly, piece by piece. > > > Best regards, > > Tiago > > > Em sex., 7 de ago. de 2026 às 09:27, Alan C. Assis <[email protected]> > escreveu: > > > Hi Matteo, > > > > I think you summarized it very well. > > > > Tomek, Nathan and Alin, I think you are missing an important point: > > > > https://github.com/zephyrproject-rtos/hal_espressif > > > > Espressif already maintains the HAL of Zephyr (inside Zephyr repo), which > > is completely different from that esp-hal used by NuttX. > > You can see it by looking at the history, they submit commits mostly > > daily, including PR from esp-hal maintainer that are there but are not in > > ESP-HAL repo. > > The only reason that esp-hal exists is because we (including /me as > > Espressifer at that time) knew that NuttX was not open to using a HAL like > > Zephyr was doing and will not create a esp-hal for us. > > > > It could sound ironic, but maybe it makes more sense for NuttX to use > > Zephyr HAL directly, at least we know they are taking care of it. > > > > BR, > > > > Alan > > > > On Thu, Aug 6, 2026 at 4:28 PM Matteo Golin <[email protected]> > > wrote: > > > >> These are all true points. I also think the decision about the ESP HAL was > >> made before my time, so I wouldn't know if there was a vote or not. That > >> shouldn't stop us from conducting proper votes going forward, though. > >> > >> For the record, I'm on-board with the fork that we can submit patches to. > >> This is actually a similar approach my rocketry team takes with NuttX; > >> they > >> have a custom fork to get their own driver stuff in so they can continue > >> development, and then submit the drivers upstream when they are ready to > >> go > >> through the re-formatting/review process to make them better. I am pretty > >> certain Xiaomi also does this, and of course PX4 is similar. It seems like > >> a fork is a good idea for us here, because it's a buffering point for us > >> to > >> get the benefits of our patches before they get up-streamed to Espressif, > >> if ever. > >> > >> Laczen is right that we would need to figure out where to host the fork > >> and > >> who will maintain the fork (i.e. do we even both spending CI resources on > >> it or just continue with the NuttX CI and take up-stream backports at face > >> value with the expectation that Espressif CI has tested them). In terms of > >> formatting, I think we should keep whatever formatting method Espressif > >> has. If it's a fork external to the kernel then there is no need to comply > >> with the NuttX style guide for now, since re-formatting would make > >> back-porting changes a nightmare. If we ever transition to replacing parts > >> of the HAL within our own kernel tree, then we can format according to the > >> style guide. > >> > >> Best, > >> Matteo > >> > >> On Thu, Aug 6, 2026 at 3:02 PM Alan C. Assis <[email protected]> wrote: > >> > >> > Hi Laczen, > >> > > >> > That was what I asked in some previous emails, but it seems like they > >> are > >> > not looking at our mailing list, so I'm copying Tiago (the repo > >> > maintainer). > >> > > >> > As he already explained in the issue from June, he is very busy with > >> other > >> > high-priorities duties at Espressif. > >> > > >> > Tiago, if you had time to read this discussion, please let me know > >> whether > >> > it is fine for you to submit a contribution to our HAL fork? > >> > > >> > We understand that Espressif has its own agenda and maybe NuttX is not a > >> > priority, but I believe that an open-source project should have the > >> right > >> > to move on without being blocked by that same agenda. > >> > > >> > BR, > >> > > >> > Alan > >> > > >> > On Thu, Aug 6, 2026 at 3:48 PM Laczen JMS <[email protected]> wrote: > >> > > >> > > I don't think it is a good idea to quickly create a fork. When a fork > >> > > is created some expectations need to be clear: > >> > > > >> > > 1. Who will maintain it and ensure that new devices are added, > >> > > 2. What are the rules this fork should comply with (e.g. code > >> > formatting), > >> > > > >> > > Why not first set the rules (if any), and if there are no (if we agree > >> > > so) ask the current maintainers of esp_hal_3rdparty if they would also > >> > > do it under nuttx (cfg zephyr). > >> > > > >> > > BR, > >> > > > >> > > Jehudi > >> > > > >> > > Op do 6 aug 2026 om 20:02 schreef Felipe Moura Oliveira < > >> > > [email protected]>: > >> > > > > >> > > > Unfortunately, I was not here when the dependency on Espressif's > >> > > 3rd-party > >> > > > repository was added. I tracked it down, and it was introduced in > >> PR: > >> > > > https://github.com/apache/nuttx/pull/8816. > >> > > > File: > >> > > > > >> > > > >> > > >> https://github.com/apache/nuttx/blob/17f7f6e86d9c045df53c65213d0c83487746d61d/arch/risc-v/src/espressif/Make.defs#L40-L59 > >> > > > > >> > > > At that time, I was not on this mailing list. Could someone from > >> that > >> > > > period check if a formal vote was held regarding the adoption of a > >> > kernel > >> > > > dependency on an external repository? > >> > > > > >> > > > If no vote was conducted back then, creating a fork of the 3rd-party > >> > > > repository and bringing it under the NuttX organization will correct > >> > this > >> > > > point. > >> > > > > >> > > > > >> > > > Em qui., 6 de ago. de 2026 às 14:43, Matteo Golin < > >> > > [email protected]> > >> > > > escreveu: > >> > > > > >> > > > > I believe it would still be a code change, since our fork will > >> > diverge > >> > > and > >> > > > > it will also presumably be used instead of the ESP HAL in the > >> kernel > >> > at > >> > > > > some point. I just think the vote would be useful in case people > >> > > disagree > >> > > > > with the fork approach. It also a rather major change. > >> > > > > > >> > > > > Best, > >> > > > > Matteo > >> > > > > > >> > > > > On Thu, Aug 6, 2026, 1:35 p.m. Felipe Moura Oliveira < > >> > > [email protected]> > >> > > > > wrote: > >> > > > > > >> > > > > > Since creating a fork of a repository and initially using it > >> > "as-is" > >> > > does > >> > > > > > not involve any actual code modifications, would a formal vote > >> ? In > >> > > other > >> > > > > > words, we aren’t change any code. > >> > > > > > > >> > > > > > > >> > > > > > *--Felipe Moura de Oliveira* > >> > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > >> > > > > > > >> > > > > > On Thu, 6 Aug 2026 at 13:09 Gregory Nutt <[email protected]> > >> > > wrote: > >> > > > > > > >> > > > > > > Apache votig rules for code changes work differently. See > >> Votes > >> > on > >> > > > > code > >> > > > > > > modification > >> > > > > > > in https://www.apache.org/foundation/voting.html Basically > >> all > >> > > voting > >> > > > > > > members have a veto right and can stop any code change. > >> > > > > > > > >> > > > > > > So, it is important to get concurrence before the vote or, at > >> > > least, > >> > > > > > > assure that no one is dramatically opposed to any code change. > >> > > This is > >> > > > > > > where you get to use you people skills and power of > >> persuasion. > >> > > > > > > ________________________________ > >> > > > > > > From: Matteo Golin <[email protected]> > >> > > > > > > Sent: Thursday, August 6, 2026 8:51 AM > >> > > > > > > To: [email protected] <[email protected]> > >> > > > > > > Subject: Re: Discussing the governance of NuttX’s > >> > esp-hal-3rdparty > >> > > > > > > dependency > >> > > > > > > > >> > > > > > > Hold on Alan, I think we should have a vote on it. I also > >> think > >> > it > >> > > > > needs > >> > > > > > > some more discussion to decide on a way to approach making the > >> > new > >> > > HAL > >> > > > > > > since there seems to be some opposing views about forking, > >> > making a > >> > > > > > custom > >> > > > > > > one, etc. > >> > > > > > > > >> > > > > > > It hasn't been very long since we opened this thread, maybe we > >> > can > >> > > > > reach > >> > > > > > > out to our Espressif contributors directly to ask them for > >> > comment > >> > > in > >> > > > > > case > >> > > > > > > they did not monitor this thread. > >> > > > > > > > >> > > > > > > Best, > >> > > > > > > Matteo > >> > > > > > > > >> > > > > > > On Thu, Aug 6, 2026 at 11:02 AM Alan C. Assis < > >> [email protected] > >> > > > >> > > > > wrote: > >> > > > > > > > >> > > > > > > > Ok, since we didn't hear from Espressif contributors and > >> > > everybody > >> > > > > > agreed > >> > > > > > > > it is better to have a HAL under NuttX than under an > >> external > >> > > > > company, > >> > > > > > > > let's create it. > >> > > > > > > > > >> > > > > > > > BR, > >> > > > > > > > > >> > > > > > > > Alan > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > On Wed, Aug 5, 2026 at 2:48 PM Alan C. Assis < > >> > [email protected]> > >> > > > > > wrote: > >> > > > > > > > > >> > > > > > > > > Yes, I agree we need a common agreement to implement such > >> > > > > > modification. > >> > > > > > > > > And today we are more divided about AI usage. > >> > > > > > > > > > >> > > > > > > > > But I agree we are discussing two or three separated > >> things. > >> > > > > > > > > > >> > > > > > > > > Let's return to the main issue. First we need to know if > >> the > >> > > > > > Espressif > >> > > > > > > > > contributors agree to contribute to a esp-hal hosted on > >> NuttX > >> > > side. > >> > > > > > > > > > >> > > > > > > > > BR, > >> > > > > > > > > > >> > > > > > > > > Alan > >> > > > > > > > > > >> > > > > > > > > On Wednesday, August 5, 2026, Matteo Golin < > >> > > [email protected] > >> > > > > > > >> > > > > > > > wrote: > >> > > > > > > > > > >> > > > > > > > >> > I disagree with the suggestion that those interested > >> in > >> > > > > exploring > >> > > > > > > > this > >> > > > > > > > >> path should just create a separate experimental project. > >> In > >> > an > >> > > > > > > > open-source > >> > > > > > > > >> community, every contribution and idea is valuable, even > >> if > >> > it > >> > > > > > > > introduces > >> > > > > > > > >> disagreement or ultimately fails. > >> > > > > > > > >> > >> > > > > > > > >> Yes, in spirit. This is why the idea is being discussed > >> > here. > >> > > But > >> > > > > > > > >> ultimately, without consensus, we can't just have > >> everyone's > >> > > > > > > > experimental > >> > > > > > > > >> ideas merged into NuttX to succeed/fail there. That is > >> why > >> > we > >> > > are > >> > > > > > > > >> discussing it first. NuttX mainline is not a playground > >> for > >> > > > > > anything, > >> > > > > > > > >> that's why we take pains to ask for testing logs and get > >> > > proper PR > >> > > > > > > > >> descriptions. > >> > > > > > > > >> > >> > > > > > > > >> The ESP HAL is used in many devices. One such device is > >> my > >> > > ESP32 > >> > > > > > based > >> > > > > > > > >> rocket altimeter. This altimer is responsible for > >> deploying > >> > > > > > parachutes > >> > > > > > > > on > >> > > > > > > > >> my very expensive rocket. If that goes wrong, my rocket > >> > > crashes > >> > > > > and > >> > > > > > I > >> > > > > > > > lose > >> > > > > > > > >> a lot of money and time. I don't want to rely on an > >> > > experimental, > >> > > > > AI > >> > > > > > > > >> written HAL for this. I much prefer the iterated, > >> strictly > >> > > tested > >> > > > > > and > >> > > > > > > > >> maintained HAL by the company itself. A NuttX written HAL > >> > > would > >> > > > > need > >> > > > > > > to > >> > > > > > > > be > >> > > > > > > > >> well tested, understood and maintained for me to want to > >> > make > >> > > the > >> > > > > > > > switch. > >> > > > > > > > >> These changes have real consequences, and for companies > >> much > >> > > > > larger > >> > > > > > > than > >> > > > > > > > >> just lowly old me and my hobby rockets. Keeping > >> guarantees > >> > for > >> > > > > users > >> > > > > > > is > >> > > > > > > > >> the > >> > > > > > > > >> utmost concern and we always need to weigh that when > >> > > considering > >> > > > > > > > options. > >> > > > > > > > >> We are unfortunately not free to just experiment with > >> > > anything in > >> > > > > > > > mainline > >> > > > > > > > >> when we'd like. > >> > > > > > > > >> > >> > > > > > > > >> Matteo > >> > > > > > > > >> > >> > > > > > > > >> On Wed, Aug 5, 2026, 12:52 p.m. Matteo Golin < > >> > > > > > [email protected]> > >> > > > > > > > >> wrote: > >> > > > > > > > >> > >> > > > > > > > >> > What Raiden mentioned is right: AI generated or not, > >> this > >> > is > >> > > > > > > something > >> > > > > > > > >> we > >> > > > > > > > >> > have to discuss with the Espressif maintainers. They > >> are > >> > > > > > incredibly > >> > > > > > > > >> active > >> > > > > > > > >> > and keep our ESP support up to date. As much as I want > >> our > >> > > own > >> > > > > > NuttX > >> > > > > > > > >> HAL, > >> > > > > > > > >> > we have to decide if it's worth trading for the burden > >> of > >> > > having > >> > > > > > our > >> > > > > > > > >> own, > >> > > > > > > > >> > non-Espressif maintainers for it. I'm incredibly > >> against > >> > > the AI > >> > > > > > > > rewrite, > >> > > > > > > > >> > but at this time I would also be against a by-hand > >> rewrite > >> > > > > unless > >> > > > > > we > >> > > > > > > > >> > somehow get continued support maintaining it, either by > >> > > > > Espressif > >> > > > > > or > >> > > > > > > > >> other > >> > > > > > > > >> > devs, at the level we get from Espressif right now. > >> That > >> > > kind of > >> > > > > > > > >> maintainer > >> > > > > > > > >> > work is super valuable to NuttX, which already has few > >> > > > > > maintainers. > >> > > > > > > > >> > > >> > > > > > > > >> > Also, respectfully, thinking that a new HAL rewritten > >> to > >> > > follow > >> > > > > > > NuttX > >> > > > > > > > >> > idioms will have bit-by-bit identical output to the > >> > > original ESP > >> > > > > > HAL > >> > > > > > > > is > >> > > > > > > > >> > wishful thinking. All kinds of things, including > >> internal > >> > > data > >> > > > > > > > >> structures, > >> > > > > > > > >> > will be different. Unless I am misunderstanding that > >> > > > > proposition, > >> > > > > > > that > >> > > > > > > > >> is > >> > > > > > > > >> > definitely not going to work as a testing plan for a > >> new > >> > > HAL. > >> > > > > > > > >> > > >> > > > > > > > >> > Matteo > >> > > > > > > > >> > > >> > > > > > > > >> > On Wed, Aug 5, 2026, 12:44 p.m. Tomek CEDRO < > >> > > [email protected]> > >> > > > > > > wrote: > >> > > > > > > > >> > > >> > > > > > > > >> >> On Wed, Aug 5, 2026 at 4:27 PM Marco C. < > >> > > > > > [email protected]> > >> > > > > > > > >> wrote: > >> > > > > > > > >> >> > Let me try to explain the methodology so you can > >> open > >> > > your > >> > > > > > mind: > >> > > > > > > > >> >> > (..) > >> > > > > > > > >> >> > Open your mind. Peace. > >> > > > > > > > >> >> > Marco Casaroli > >> > > > > > > > >> >> > >> > > > > > > > >> >> We are open-minded Marco, very, it is highly unfair to > >> > say > >> > > we > >> > > > > are > >> > > > > > > > not. > >> > > > > > > > >> >> > >> > > > > > > > >> >> You need to take into a consideration that all NuttX > >> > > related > >> > > > > work > >> > > > > > > is > >> > > > > > > > >> >> done in our free time at the expense of any other > >> tasks > >> > > > > sometimes > >> > > > > > > our > >> > > > > > > > >> >> families and so called private human life. > >> > > > > > > > >> >> > >> > > > > > > > >> >> We are also people taking personal responsibility for > >> the > >> > > > > > products > >> > > > > > > > >> >> development, its delivery, and maintenance. If things > >> > take > >> > > too > >> > > > > > > > complex > >> > > > > > > > >> >> and too long to deliver we are out of business. If > >> things > >> > > fail > >> > > > > on > >> > > > > > > > >> >> production we are out of business. If we are unable to > >> > > maintain > >> > > > > > and > >> > > > > > > > >> >> service products we are out of business. This out of > >> > > business > >> > > > > > also > >> > > > > > > > >> >> means measurable financial responsibility. > >> > > > > > > > >> >> > >> > > > > > > > >> >> Most of us are owners of the company, business, > >> product. > >> > We > >> > > > > have > >> > > > > > > > >> >> experiences that made us have solid stand on the > >> ground > >> > and > >> > > > > think > >> > > > > > > the > >> > > > > > > > >> >> way we think. Its okay to play around and experiment, > >> but > >> > > its > >> > > > > not > >> > > > > > > > okay > >> > > > > > > > >> >> to impose experiments on everyone around, like so > >> called > >> > > modern > >> > > > > > > world > >> > > > > > > > >> >> does right now. We cannot build without solid > >> > foundations, > >> > > when > >> > > > > > all > >> > > > > > > > >> >> components change all the time, including software and > >> > > recently > >> > > > > > > even > >> > > > > > > > >> >> hardware components. Its a big complex mess right > >> now. We > >> > > do > >> > > > > not > >> > > > > > > want > >> > > > > > > > >> >> to make it worse or even take part ourselves. This is > >> > > clearly > >> > > > > > > > >> >> destructive. > >> > > > > > > > >> >> > >> > > > > > > > >> >> We can play around but then we need to provide > >> > alternative > >> > > path > >> > > > > > to > >> > > > > > > be > >> > > > > > > > >> >> selected, while foundations must remain rock solid, so > >> > > people > >> > > > > > have > >> > > > > > > > >> >> choice. I understand you use free AI to create stuff, > >> but > >> > > in > >> > > > > the > >> > > > > > > end > >> > > > > > > > >> >> there are living humans paying bills daily that need > >> to > >> > > process > >> > > > > > > that > >> > > > > > > > >> >> also for free in their free time. > >> > > > > > > > >> >> > >> > > > > > > > >> >> My proposition for the people with lots of free time > >> is > >> > to > >> > > > > create > >> > > > > > > an > >> > > > > > > > >> >> experimental but separate AI NuttX rewrite and see > >> how it > >> > > goes. > >> > > > > > It > >> > > > > > > > >> >> should be a win-win scenario where we can cope with > >> basic > >> > > tasks > >> > > > > > in > >> > > > > > > > >> >> NuttX while the other project may explore new worlds. > >> > > > > > > > >> >> > >> > > > > > > > >> >> Peace :-) > >> > > > > > > > >> >> > >> > > > > > > > >> >> -- > >> > > > > > > > >> >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >> > > > > > > > >> >> > >> > > > > > > > >> > > >> > > > > > > > >> > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > -- > >> > > > > >> > > > *--Felipe Moura de Oliveira* > >> > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > >> > > > >> > > >> > > -- Matteo Golin
signature.asc
Description: PGP signature
