Skip to content

deprecate NVIC.{clear,set}_pending in favor of NVIC::{un,}pend #120

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

Merged
merged 1 commit into from
Oct 27, 2018

Conversation

japaric
Copy link
Member

@japaric japaric commented Oct 27, 2018

NVIC::{un,}pend are static methods that don't require an instance of NVIC to be
invoked.

Rationale: These operations perform writes to stateless registers so they can
not result in data races.

More tricky is the question of whether letting the user call these from any
execution context without any critical section or other means of synchronization
can result in memory unsafety when used in conjunction with methods like
NVIC.{get,set}_priority that do require an instance of NVIC. I can't foresee any
trouble given that these methods (e.g. pend and set_priority) operate on
different registers.

NVIC::{un,}pend are static methods that don't require an instance of NVIC to be
invoked.
@japaric japaric requested a review from a team as a code owner October 27, 2018 11:04
japaric added a commit that referenced this pull request Oct 27, 2018
required to make a release

we can publish now or wait for #120
@japaric japaric mentioned this pull request Oct 27, 2018
Copy link
Contributor

@therealprof therealprof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it. Was always a bit of pain...

@therealprof
Copy link
Contributor

bors r+

bors bot added a commit that referenced this pull request Oct 27, 2018
120: deprecate NVIC.{clear,set}_pending in favor of NVIC::{un,}pend r=therealprof a=japaric

NVIC::{un,}pend are static methods that don't require an instance of NVIC to be
invoked.

Rationale: These operations perform writes to stateless registers so they can
*not* result in data races.

More tricky is the question of whether letting the user call these from any
execution context without any critical section or other means of synchronization
can result in memory unsafety when used in conjunction with methods like
NVIC.{get,set}_priority that do require an instance of NVIC. I can't foresee any
trouble given that these methods (e.g. pend and set_priority) operate on
different registers.


Co-authored-by: Jorge Aparicio <[email protected]>
@bors
Copy link
Contributor

bors bot commented Oct 27, 2018

Build succeeded

@bors bors bot merged commit 92f269f into master Oct 27, 2018
@bors bors bot deleted the nvic-pend branch October 27, 2018 11:19
japaric added a commit that referenced this pull request Oct 27, 2018
required to make a release

we can publish now or wait for #120
japaric added a commit that referenced this pull request Oct 27, 2018
bors bot added a commit that referenced this pull request Oct 27, 2018
121: v0.5.8 r=therealprof a=japaric

required to make a release

we can publish now or wait for #120

Co-authored-by: Jorge Aparicio <[email protected]>
adamgreig pushed a commit that referenced this pull request Jan 12, 2022
or the user defined interrupts will be discarded when using fat LTO as seen
in #120

closes #120
adamgreig pushed a commit that referenced this pull request Jan 12, 2022
121: link.x: EXTERN(__INTERRUPTS) must come before PROVIDED r=therealprof a=japaric

or the user defined interrupts will be discarded when using fat LTO as seen
in #120

fixes #120

r? @rust-embedded/cortex-m (anyone)

Co-authored-by: Jorge Aparicio <[email protected]>
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

Successfully merging this pull request may close these issues.

2 participants