The proposed DMA API is unsafe about embedonomicon HOT 1 OPEN

I thought about the use of StableDeref a bit more. The guarantees it provides with regard to DerefMut are a bit hard to grasp. For example, Vec implements StableDeref, even though it can re-allocate if you push to it. My understanding is that the stable address guarantee for DerefMut types only holds as long as you don't call &mut self methods on the type itself. But the documentation doesn't explicitly state that.

Let's take a step back. Here is what I gather are the minimum requirements a generic safe DMA buffer type has to fulfill:

1. It must be a pointer.
   Otherwise the buffer would be part of the Transfer struct and move around with it on the stack, which we cannot allow (see 3).
2. The referenced buffer must be valid (i.e. not freed) for the length of the transfer.
   Otherwise the compiler could re-use the buffer space for other data, while the DMA was still reading from/writing to it.
3. The referenced buffer must be at a stable address for the length of the transfer.
   Same reason as 2. Additionally, data returned from DMA reads would be incomplete when the buffer moved in the meantime.

Requirements 2 and 3 must be true even if we take mem::forget into account: If the Transfer is mem::forgetten, we won't be able to stop the DMA since the destructor is not run. So the buffer needs to stay valid and stable afterwards.

Looking at the types StableDeref is implemented for out of the box, it looks like all of them fulfill the above requirements. So provided I'm not missing an essential requirement above, using StableDeref for DMA buffers should be fine. In fact, it seems to be exactly what we need in terms of guarantees.

from embedonomicon.