Pat Pannuto

Rebased and pulled in the changes from the branch which updates the types too. --- > We also need to decide what to do in the digest and entropy HILs....

I updated the whole thing to do both because after my [comment with exemplar expanding everything](https://github.com/tock/tock/pull/4443#issuecomment-2898542341) there was one agreeing comment and then silence. I [did say I updated both](https://github.com/tock/tock/pull/4443#issuecomment-2978298651),...

I reverted (well, removed the commit) with the type name changes. I squashed the digest commit in with the rest since it's all one logical change anyway.

> I do not believe creation capability MUST be limited to top-level board files. There could be other acceptable mechanisms. Do you have any specific use cases in mind? From...

> capabilities can be used in components but must be passed in I believe that was the design point we came to on the call this morning.

> I could imagine a helper (maybe a component) that creates capabilities [The kernel already provides a helper](https://github.com/tock/tock/blob/754e045fe8cd22be3d8cd3a7a470f17bf3cbd846/kernel/src/utilities/helpers.rs#L25). Creating capabilities is currently a one-liner, i.e. let memory_allocation_cap = create_capability!(capabilities::MemoryAllocationCapability); This...

> Does Rust care if you create a struct and implement all capabilities for it, and then use it for something that only needs one? I believe that would be...

🤯 ... _wow_ does Rust make it difficult to contain `unsafe` in practice... Does this only "work" because the macro happens to be defined in crate that does allow the...

It appears the answer to that is yes, and it's a deliberate design choice: https://github.com/rust-lang/rust/issues/110613#issuecomment-1516813435

It's not problematic for ARM, which defines the suites of addresses which can be used for memory-like things. - (That said `0x80... — 0x9f...` is reserved for SRAM-like structures, "Memory...