Unsafe register access option.

Following the definition of unsafety as described in Ferrocene spec and Rust reference, unsafe code may result in undefined behavior.

In our microcontrollers we can trigger an undefined behavior for some peripherals if some write/read order is not followed.
Therefore I think that all write access and read access that has side effect (SVD support this attribute) shall be declared as unsafe just because the HW could have some undefined behavior.
HAL or Low Level Driver in Rust shall solve the safety issue by providing API that forbid to trigger undefined behavior.

Moreover I find someway a contradiction that presently all register access (with some exception) is considered safe while if I call a low level driver implemented in C is considered unsafe. I see a clear similarity between register access and C API.

Do I miss something ?

Proposal:

Provide a svd2rust option to mark all all write access and read access that has side effect as unsafe.

This will not break backward compatibility and it will let to migrate to a safer implementation.

PS. Someone in embassy team share the same concerns.

Begin with the proposal and its Ferrocene and Rust safety references, then trace where svd2rust generates register read and write access. Done means an option can mark all writes and side-effect reads unsafe while preserving the default behavior; the issue names no file or test, so the implementation scope needs project-level investigation.