esp-open-lwip
esp-open-lwip copied to clipboard
pfalcon
Update with changes from ESP SDK 2.0
There are a few fixes in the ESP SDK 2.0 release to their fork of lwip. It would be nice to have them merged in here.
Feel free to submit patch showing the changes, and we together will see if they're nice or not.
I made a fork here https://github.com/jeffsenn/esp-open-lwip -- take a look and see if you like it
Hi pfalcon and jeffsenn, I'm trying to understand esp-open-lwip and esp-open-sdk repositories here at github. When you clone recursively esp-open-sdk it comes with nonOs SDK 2.0 as well but it seems that it relies on esp-open-lwip that's based upon SDK 1.5 and has more libraries than jeffsenn's esp-open-lwip repository? what lwip stands for and jeffsenn did you wrote those libraries by yourself?
@jeffsenn It looks like a lot of changes could you make a PR? The issue is that there is a lot of reformatted code extra spaces/tabs etc which are irrelevant it would be nice if you could excluse whitespace formatting from the PR in order to keep modifications as relevant as possible. @pfalcon would you still maintain a branch for 2.0 ?
a lot of reformatted code extra spaces/tabs etc
That's why I'm not keep on merging it. It adds noise, somebody would need to prove that it anything else but noise.
would you still maintain a branch for 2.0 ?
The branch as used by esp-open-sdk works perfectly with SDK 2.0, as exemplified by MicroPython and non-trivial networking it supports.
Generally, what this project for is:
- To track vendor mess-releases until p.2.
- To find the closest upstream revision corresponding to the last used mess-release.
- Extract the most minimal patch against upstream (undoing vendor mess).
- Rebase onto the current upstream release.
- Never again deal with vendor mess.
Doing too much of p.1 contradicts final goal, p.5. And contribution to p.2 are the most welcome, and I'm not sure that any other contributions are useful, sorry (at best, they add noise which will be a problem for p.3 & 4, worse, they just continue vicious "mess" cycle).
Hi @pfalcon thank you for response. We use this repo in Sming You are saying that you are not interrested in adding fixes here but just to keep as close as possible to Espressif? Because I want to know what is best path for fixing small bugs or some lwip_options if I should make a PR here (#5 #6 ) or just update a patch file in sming project (downstream)
You are saying that you are not interrested in adding fixes here but just to keep as close as possible to Espressif?
No, as close as possible to the lwIP mainline: http://savannah.nongnu.org/projects/lwip/ . Any fixes should go directly to them.
The esp8266 changes from this repository were finally rebased on top of the upstream lwIP repo, see https://github.com/pfalcon/esp-open-lwip/issues/7 . Any further changes will be/should be done against that repository.