Embedded-hal: [Discussion] HAL goals, objectives, and expectations

Created on 12 Nov 2018  路  2Comments  路  Source: rust-embedded/embedded-hal

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

discussion

Most helpful comment

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.

All 2 comments

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.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Rahix picture Rahix  路  5Comments

hannobraun picture hannobraun  路  8Comments

therealprof picture therealprof  路  13Comments

tib888 picture tib888  路  3Comments

dbrgn picture dbrgn  路  10Comments