Consider reexporting esp-idf-sys in HAL and SVC as a `sys` module (ditto for a `hal` module in SVC) about esp-idf-hal HOT 7 CLOSED

But would it be just EspError? I recall TickType_t as well? And then there is a lot of pub stuff from esp-idf-sys used in esp-idf-hal in the form of From trait implementations. While - for the latter - I don't expect users to reach out to the esp-idf-sys types, who knows? (UPDATE: yeah, also all handle and whatnot methods which are pub and via those you can get a handle to the raw C driver, should you need to unsafely call into ESP IDF via esp-idf-sys for whatever the current Rust driver wrappers don't support.)

Maybe we should just export all of esp-idf-sys as esp_idf_hal::sys?
But then, what about esp-idf-svc which depends on both esp-idf-sys and esp-idf-hal?
Should it re-export esp-idf-sys as esp_idf_svc::sys and esp-idf-hal as esp_idf_svc::hal?

from esp-idf-hal.

While I'm somehow OK with ^^^ (re-exporting the crates completely in sys / hal modules), let's not forget that the original root cause of the poster's problems is that he simply cannot build esp-idf-sys on his machine. And that problem won't magically disappear by doing re-exports.

from esp-idf-hal.

Agreed that it won't fix all of the poster's original problems. I'm just recalling similar issues I had over with Http, Hyper, and Warp, where I was constantly getting warnings from rustc that a http::Request in my crate is not the same as the http::Request that Hyper wanted, and Warp wanted yet another http::Request.

from esp-idf-hal.

Thinking about this some more... for now I want to be conservative, and just expose EspError (at the root) because it is part of the public interface of esp-idf-hal. We have a lot of code that returns Result<T, EspError>, and it'd be nice to not have to grab that second type from esp-idf-sys.

If there are other types similarly situated, we could use those, too, but I can't think of any that are exposed via the API. The only one that has user implications (not necessarily needed in APIs) that I can think of is CONFIG_FREERTOS_HZ (which I would rename to SYSTEM_TICKS_PER_SECOND).

from esp-idf-hal.

Thinking about this some more... for now I want to be conservative, and just expose EspError (at the root) because it is part of the public interface of esp-idf-hal. We have a lot of code that returns Result<T, EspError>, and it'd be nice to not have to grab that second type from esp-idf-sys.

If there are other types similarly situated, we could use those, too, but I can't think of any that are exposed via the API. The only one that has user implications (not necessarily needed in APIs) that I can think of is CONFIG_FREERTOS_HZ (which I would rename to SYSTEM_TICKS_PER_SECOND).

But what I'm saying is that a lot of esp-idf-sys types are already part of the public interface of esp-idf-hal and esp-idf-svc. Case in point from just 3 minutes ago. And there are more - as in all peripherals also expose the original esp-idf-sys types.

So really - it should be all or nothing - either we expose all in a sys submodule (BTW - this is what Embassy HALs seem to do for their PAC crates which are roughly equivalent to our sys crate), or we do nothing.

from esp-idf-hal.

I'd feel a bit better if we could only do this for types and not functions, but I imagine that's not terribly feasible.

At least all of the functions are marked unsafe, though.

from esp-idf-hal.

Raw pointers (because for the most part this is what the esp-idf-svc handles are and also what we expose) are just as safe/unsafe as unsafe functions.

Both are completely safe until you call them (unsafe functions) or try to dereference them (raw pointers).

So yeah, user would still be protected, as dealing with these types and functions would require an unsafe {} block in both cases.

from esp-idf-hal.