error when compiling mio

[schphil]

hi, first of all, thanks for your example, pretty straightforward.
i would like to use the crate mio for another project (this target is not supported and I'm trying to make it work). when compiling, I get a lot of errors related to libc, e.g:

obviously these variables are not defined in libc. I tried to find these variables, but unfortunately I only found them in an older commit in newlib-esp32. do you know where they are defined? is it even possible to compile the crate for this target? please forgive me for asking these questions, as I am still quite new to this field. I would appreciate any help. thanks in advance!

[ivmarkov]

Unfortunately, it won't be as easy as figuring out "from where these variables come".

If I'm not mistaken, these are from the kqueue OS functionality. mio needs either kqueue or epoll to work, however I don't think ESP-IDF supports either. ESP-IDF does support the older select and poll though, but mio is somewhat not so keen on supporting those (as in a lot of changes and performance issues - not that large number of file descriptors are a real issue on the ESP-IDF.)

You might have better luck with smol-rs, which at least does have a patch for support of poll.

[schphil]

thanks for your quick reply. the problem is that i want to make use of hap-rs and i don't know if i can easily adapt to smol-rs. i'm trying to dig deeper into it. if you have any further hints, please let me know. i'll close this one for now. thanks!

[ivmarkov]

Difficult task... unless the owner of hap-rs would like to make his crate async runtime agnostic. Meaning, it should be able to work with any async runtime (be it tokyo, async-std or smol-rs).

This is by the way the general trend in Rust recently - crates should not depend on a concrete async runtime. The runtime should be chosen by the consumer of the crate - so you might have a strong point convincing the author to make those changes. Especially if you are willing to contribute. Whether that's realistic - given how many moving parts are there right now in Rust async support - I don't know. In any case I would highly suggest you take a look at the hap-rs crate in terms of its memory, code footprint and other dependencies (beyond tokyo). If it is too big, then it is a no go anyway, as you are targeting device with < 500KB RAM and < 2MB flash (on average).

[schphil]

ok, i'll see what i can do about the async runtimes. i already had the flash memory bigger in mind, but not the ram. good point! thanks for the good support.

[schphil]

i reached out to the owner of hap-rs, since haps-rs has strong dependency on tokio's net feature (this is where the trouble starts), it might take a while to have something working with the xtensa target.

in the meantime, i thought of making the esp-homekit-sdk available with your cargo-pio crate. do you have any comments/thoughts on that? thanks!

[jasta]

I'm looking at reviving support for tokio (many have tried before, but I think we're getting quite close this time). See tokio-rs/mio#1687 to follow along with the first steps.

[ivmarkov]

@jasta I have not looked at your patch yet, but to confirm: you DO plan to support a poll()+eventfd() combo, in addition to a poll()+pipe() combo, right?

Bottom line is, the pipe() API is not supported by the ESP IDF. However, they do support a subset of the Linux eventfd() API.

[jasta]

Correct. Right now I have mio tests fully passing on Linux with poll+eventfd.

[ivmarkov]

I really need to upstream my changes to polling which make it compatible with the ESP IDF... :(

[jasta]

EDIT: Let's move this discussion over to #153 .