Hi all,
As previously mentioned, I'm working on a redesign of tock-registers which
focuses on soundness and unit-testability. My implementation is at PR 11
<https://github.com/tock/tock-registers/pull/11>. At this point, I believe
that the design is the correct path forward for tock-registers. I am
looking for additional feedback on the design, so if you have not taken a
look at it yet please do so.
I'm hoping that at next week's core WG call, we can finalize the macro's
name <https://github.com/tock/tock-registers/pull/11#discussion_r3275870143>
and
make the decision to move forward with the design (at which point I will
break it up into smaller non-draft PRs).
-Johnathan Van Why
Hi all,
I am currently working on a tock-registers redesign which:
1. Resolves the soundness issue
<https://github.com/tock/tock-registers/issues/4> with register_structs.
2. Makes it relatively easy to unit-test driver implementations.
Meeting these requirements without using procedural macros is not really
feasible (the complexity of the required macro vastly exceeds the amount of
complexity manageable in a macro_rules! macro). As a result, I plan to use
procedural macros in tock-registers, and furthermore, those procedural
macros will need to depend on the syn, quote, and proc-macro2 crates.
I've opened PR 4814 <https://github.com/tock/tock/pull/4814> to extend
Tock's external dependencies policy to allow for these macros. Please take
a look at it and provide your input. Feedback has already resulted in one
change: my tock-registers prototype now supports a build mode where macro
expansion is performed up-front, allowing the procedural macros to be
omitted from the final build.
For reference, my current prototype for the new tock-registers is at
tock-registers
PR 11 <https://github.com/tock/tock-registers/pull/11>. Feel free to take a
look at that and provide feedback on it as well!
Thank you,
Johnathan Van Why
