no_std support, keeping MSRV#603
Conversation
Cargo.toml
Outdated
There was a problem hiding this comment.
Can we feature-guard hashbrown somehow? We can probably just not export chunks of the library that rely on a HashMap, most of the library is still useful without it.
There was a problem hiding this comment.
I pushed a couple of commits to do this, let me know what you think of the approach
55e2a03 to
9f79ab9
Compare
|
Need CI use approval. |
I Approved the CI to run |
We have to do it every time any new push happens. I have zero clue what this is even intended to solve, but its super obnoxious. Obnoxious enough that I'd start thinking about something other than GH actions at this point for CI. |
|
CI should be fixed with latest push. Sorry for the hassle. |
|
And one more... |
|
OK, looks like CI passes, but there is some strangeness in the display with three additional line items showing as "expected". |
|
What do we think about bumping the MSRV to edition 2018 / 1.31.0? This would affect rust-lightning too, since it is at 1.30.0. |
I think it's planned in the next few months (#510 (comment)). |
dec4ab4 to
ff18a01
Compare
TheBlueMatt
left a comment
There was a problem hiding this comment.
Generally looks good. I think we should wait for/work on rust-bitcoin/bitcoin_hashes#126 or rust-bitcoin/bitcoin_hashes#127 first and then use that here.
|
In the meantime, I added an embedded test, similar to the one in bitcoin_hashes. 512KB minimum is required because of the amount of stack that secp256k1 requires to build a context, even in lowmemory mode. |
866016d to
1805550
Compare
|
|
4e267b6 to
c715916
Compare
|
So |
TheBlueMatt
left a comment
There was a problem hiding this comment.
High level looks good. Can you squash up the commits and fix the FIXMEs? Lets land this!
Yea, probably go ahead and open a PR there or chat with @RCasatta about doing it. Maybe we can simplify this PR to export fewer things for now and land it quicker, then we can expand the things exposed in |
|
Opened rust-bitcoin/bitcoin_hashes#128 and adjusted this one to point to that |
e930a41 to
2e69c77
Compare
|
Ah, sorry for another remark, I was just going through my notifications and saw that there is a non-alpha release of |
Ah, great. But we'll have to upgrade and release bitcoin_hashes first, otherwise there's a semver version conflict. |
|
An updated version of |
2d416dd to
c50a5f2
Compare
|
updated deps, rebased and squashed |
TheBlueMatt
left a comment
There was a problem hiding this comment.
One question, two tiny comments, and I'm otherwise happy :)
contrib/test.sh
Outdated
There was a problem hiding this comment.
If we're just gonna require std for tests, I'm a bit confused why a bunch of #[cfg(test)] blocks have std/no-std feature checks. Is it just that we intend to support no_std tests but don't yet and its WIP to be done in a followup?
There was a problem hiding this comment.
Comment was wrong, and we do indeed test with no-std below. Fixed.
c50a5f2 to
8af260e
Compare
8af260e to
f4ec84c
Compare
|
Note that this now requires a major version bump as its "breaking" to update the bitcoin_hashes dependency. I think that's fine and don't really care about the merkle block deprecated functions, just wanted to flag it. |
Based on the original work by Justin Moon. *MSRV unchanged from 1.29.0.* When `std` is off, `no-std` must be on, and we use the [`alloc`](https://doc.rust-lang.org/alloc/) and core2 crates. The `alloc` crate requires the user define a global allocator. * Import from `core` and `alloc` instead of `std` * `alloc` only used if `no-std` is on * Create `std` feature * Create `no-std` feature which adds a core2 dependency to polyfill `std::io` features. This is an experimental feature and should be used with caution. * CI runs tests `no-std` * MSRV for `no-std` is 1.51 or so
f4ec84c to
bba57d7
Compare
@TheBlueMatt to clarify, are you saying that we could remove the deprecated funcs but you don't feel strongly about it? (I don't feel strongly either) |
TheBlueMatt
left a comment
There was a problem hiding this comment.
@TheBlueMatt to clarify, are you saying that we could remove the deprecated funcs but you don't feel strongly about it? (I don't feel strongly either)
Yes.
RCasatta
left a comment
There was a problem hiding this comment.
I did a couple of tests limiting memory with the embedded test:
- with 64KB of memory the process hangs forever with the CPU looping
- with 128KB it panics with
panic Some([libsecp256k1] illegal argument. rustsecp256k1_v0_4_0_ecmult_gen_context_is_built(&ctx->ecmult_gen_ctx)) - with 256KB works correctly (secp buf size 66240 bytes)
| @@ -0,0 +1,2 @@ | |||
| export RUSTFLAGS="-C link-arg=-Tlink.x" | |||
| export CARGO_TARGET_THUMBV7M_NONE_EABI_RUNNER="qemu-system-arm -cpu cortex-m3 -machine mps2-an385 -m 1G -nographic -semihosting-config enable=on,target=native -kernel" | |||
There was a problem hiding this comment.
-m 1G on my host complain saying maximum memory for this machine is 16Mib, removing the parameter seems to work fine
qemu-system-arm: Invalid RAM size, should be 16 MiB
There was a problem hiding this comment.
Curious what is your qemu and OS version? does it work with -m 16m?
There was a problem hiding this comment.
I'm thinking of changing this to -m 1m, but it would be good to know the answer to the above to make sure it works in your env too.
There was a problem hiding this comment.
yeah, sorry.
On macOS Catalina with QEMU emulator version 5.2.0 it works only with -m 16m or without the option.
It doesn't work with -m 1m or -m 1G
There was a problem hiding this comment.
OK. Ubuntu 20.04 has qemu 4.2 and it also works without the flag. So I think I'll remove the flag if there are any other changes, or wait to a followup PR.
| #[global_allocator] | ||
| static ALLOCATOR: CortexMHeap = CortexMHeap::empty(); | ||
|
|
||
| const HEAP_SIZE: usize = 1024 * 512; // 512 KB |
There was a problem hiding this comment.
all memory available is 512Kb according to memory.x so the heap should be less, eg 256KB
There was a problem hiding this comment.
Probably not worth dismissing approvals only for this
|
Gonna merge this. We can address @RCasatta comment in a folllowup PR (and maybe make other changes to work with tiny amounts of RAM) |
TODO:
Based on the original work by Justin Moon in #528
MSRV unchanged from 1.29.0.
When
stdis off theno-stdfeature must be turned on, which turns on thealloccrate, which requires the user define a global allocator. It also pulls in thehashbrowncrate and activatesno_stdandallocsupport in a couple of dependencies.coreandallocinstead ofstdalloconly used ifstdis offstdfeatureno-stdfeature which adds a core2 dependency to polyfillstd::iofeatures. This is an experimental feature and should be used with caution.no_stdcodeno_stdis 1.51 or soFixes #409