Skip to content

[Discussion] HAL goals, objectives, and expectations #112

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

Closed
ryankurte opened this issue Nov 12, 2018 · 2 comments
Closed

[Discussion] HAL goals, objectives, and expectations #112

ryankurte opened this issue Nov 12, 2018 · 2 comments

Comments

@ryankurte
Copy link
Contributor

Hey all,

Based on the discussion around trait implementations, upgrades, and breakage mitigation I think it'd be useful to have a chat about what our goals / objectives / expectations for embedded-hal are and depending how it goes to look to refining and formalising the outcome both for our reference and to communicate to embedded-hal consumers.

Imo this library is one of the most important parts of / opportunities with embedded rust, I think there are likely to be some strong feelings (I know I have some), so let's make a point of remembering that while we may have different experiences and opinions, we're all on the same page here, working towards making the embedded rust experience excellent ^_^

Here's an absolutely non-exhaustive list of talking points to get started:

  • What is the purpose of embedded-hal?
  • What makes a trait a good or poor candidate for inclusion?
  • What stability / interoperability guarantees should we make / expect?

So, let's get started below~!

cc. @rust-embedded/hal

@therealprof
Copy link
Contributor

What is the purpose of embedded-hal?

Provide an interface to easily and generically interface between different hardware components and applications.

What makes a trait a good or poor candidate for inclusion?

A good trait needs to be generic enough to be applicable to a lot of vastly different hardware while being simple enough to allow for easy use. Both overengineered traits as well as vendor specific traits are bad candidates.

What stability / interoperability guarantees should we make / expect?

As soon as there're implementations out there using a trait (as indicated by the proven predicate) it shouldn't be changed anymore. If an incompatible modification is required for reasons which couled/were not foreseen before marking the trait(s) as proven, then a new (set of) trait(s) should be offered as replacement or extension, if possible with compatibility bridge. Breaking existing traits automatically means incompatibility of users relying on that trait in different versions which kills the user experience which, in my opinion, is the single most important aspect of anything we do.

@ryankurte
Copy link
Contributor Author

I think we can probably close this for inactivity, thanks for the thoughts!

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

No branches or pull requests

2 participants