Joining efforts

[ivmarkov]

Hi there. I'm also working on running Rust STD on top of ESP-IDF:

The thing is, when I did my work, over the course of a couple of weekends - I managed to miss the one pull request against the MabezDev Rust xtensa repo - yours. :)

Originally, I was a bit put off by the size of your changes until I realised that your patch-set is relatively small - just like mine. In fact, yours and my work are very much identical:

• We've both noticed that rust libc does have a support for newlib and we are taking advantage of that (Mabez Dev's xtensa target_env modified to = "newlib")
• ESP-IDF looks like a Posix env, so for the STD support to be unobtrusive to the libstd codebase, best is to define the xtensa targets with target_family = "unix" which routes the std calls into the std::sys::unix crate. Apparently, we both did that
• sys::unix::process does need to be stubbed out - our approach is identical - your stub is called process_freertos.rs, mine is process_none.rs
• We've both noticed that lwip does offer a BSD sockets layer; and that ESP-IDF unfortunately exposes the lwip BSD socket layer under a lwip_ prefix. You've solved that by re-declaring the BSD sockets api with custom "lwip_" path attributes, I just wrote a bunch of stubs that delegate to their lwip counterparts
• Even the sys::os support is kind of similar (fs and raw). Yours still seems stubbed out, mine at least "pretends" to call stat() correctly and return something

You have target_os = "freertos", mine is target_os = "none" and you do use some symbols from FreeRTOS, while I've managed to avoid that so far and sticked with the pthread API completely, but I've done 0 testing on mutexes and condvars so I might have missed something. For one, there is a bug (or misinterpretation) of the pthread TLS destructor API in the ESP-IDF pthread support that I hope they might fix if kindly asked - or else thread::join crashes when trying to free its TLS storage.

The bottom line is the following: I'll try to review/merge your changes into mine anyway, but if you are still pursuing STD on Rust, perhaps we can join efforts?

Or - if you've stumbled on a road-blocker (e.g. different from the sheer size of the generated executable which quickly eats up the ESP32 flash memory) - please let me know.

[reitermarkus]

Hi @ivmarkov, I have only seen this now. It would definitely make sense to join efforts on this. Did you make any more progress in the meantime?

[ivmarkov]

During November/December - yes. (You might want to take a look at https://github.com/ivmarkov/rust-esp32-std-hello which is the demo playground.)

In the past two months I was completely underwater with regular work activities, but I'm back at this now (over the weekends).

The good news is that the MabezDev fork is also back to live now, so maybe I need to again rebase my work on top of that fork.

How shall we tackle this?

[reitermarkus]

I think I will need to also rebase my fork again, since MabezDev's is now at 1.50. Once that's done I'd suggest you rebase your fork onto mine and send a PR so we can easily see the differences.

[ivmarkov]

Let me know once you rebase and I'll file my PR then.

[reitermarkus]

@ivmarkov, I'm pretty much done with my rebase. I will probably do some small refactorings still but it should be no problem to rebase again after these.