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.