Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ship a 1.0 release #22

Closed
6 of 7 tasks
thejpster opened this issue Jan 7, 2020 · 8 comments
Closed
6 of 7 tasks

Ship a 1.0 release #22

thejpster opened this issue Jan 7, 2020 · 8 comments

Comments

@thejpster
Copy link

thejpster commented Jan 7, 2020

Part of rust-embedded/wg#383

Blockers:

@jonas-schievink
Copy link
Contributor

jonas-schievink commented Jan 9, 2020

Some simple improvements to be made before 1.0:

Other blockers:

Unresolved questions:

  • Where is bare_metal::Peripheral used? Does it pull its weight? Needs more documentation.
  • Same goes for bare_metal::Nr. Would it be better to move it outside this crate? Also: Why return u8? It should probably be renamed to something like Interrupt, since it's not a trait for numbers.

@rubberduck203
Copy link
Contributor

As soon as I find the markdown version of the API checklist, I’m going to create a tracking issue for that work so items can be checked off as they’re reviewed.

@rubberduck203
Copy link
Contributor

Found it. Will open the tracking issue when time allows. https://github.com/rust-lang/api-guidelines/blob/master/src/checklist.md

bors bot added a commit that referenced this issue Jan 29, 2020
25: Remove const-fn feature r=jonas-schievink a=rubberduck203

Per #22, as of Rust v1.31 const-fn was stablized.
Removing the feature in preparation of a 1.0 release.

Related to #11

Co-authored-by: Christopher J. McClellan <[email protected]>
@therealprof
Copy link
Contributor

As agreed in the 2020-03-10 meeting we're taking off the Mutex from the 1.0 blocker list. We're aiming to have the new Mutex based on mutex-trait implemented by the arch crates instead.

@luojia65
Copy link

luojia65 commented Mar 19, 2020

Maybe Nr can be used as a parameter to configure vendor specific interrupt controller. However in this way Nr::nr should not always return a u8 (there could be more than 256 interrupts). It could be necessary to provide as Nr { type Id; fn nr(&self) -> Self::Id } (still working on it to adapt to Bumblebee's ECLIC controller)

@jonas-schievink
Copy link
Contributor

jonas-schievink commented Apr 21, 2020

IMO Nr logically belongs in architecture-specific core crates like cortex-m or cortex-m-rt.

We should check what uses it, and whether the users would see any benefit of having a traits that's shared between architectures. Maybe come up with potential use cases.

(EDIT: #32 deleted it)

@thejpster
Copy link
Author

Ticked MSRV, as it's in the README.

bors bot added a commit that referenced this issue Jun 30, 2020
35: Prepare v1.0.0 r=jonas-schievink a=adamgreig

I'm opening this PR so we can move discussions forward around v1; I am very happy to have some changes or more feedback before we go ahead with this.

Essentially, this crate is now just `CriticalSection` and `Mutex`, which are widely used and probably won't change without becoming something totally new (e.g. the new mutex-trait crate). There are some known issues (especially CSs don't disable NMI or HardFault) which perhaps could be documented and understood better, but I think are all platform-specific (cortex-m).

In this PR:

* Remove `StaticResource`: it's not been released in any published version so hasn't been proven yet; we could re-add it in a later release or separate crate
* Remove `deny(warnings)` and instead deny them in CI
* Update version to 1.0.0

We'll still want to close off #26. Otherwise I think everything from #22 is covered.

Co-authored-by: Adam Greig <[email protected]>
@adamgreig
Copy link
Member

Closed by #35.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants