The perils of pinning

While I can't really comment on how it should be implemented in Rust (I have little to no experience with the language), some of us are working on enabling such 'struct list_head' usage in BPF, and it's the same problem there of a self referential type.

One observation is that it is rare you'll be 'moving' around such a self referential struct, atleast for the list_head case. I can't find a lot of examples in the kernel where it can simply assume memcpy is equal to move for such cases. It really cannot. You have to have a 'move constructor' thing similar to C++ that does the non-trivial stuff for such special fields.

Even then, it's unlikely you're going to copy such structures around. Yes, that argument doesn't work from a language design standpoint, but at least for the BPF runtime it's going to hold. We're kind of designing the language and the standard 'BPF library' together in concert, to give a better analogy. So it's also possible to reap the benefits of such an approach.

Secondly, the core problem here is about initializing on stack and then moving into the Boxed object. Instead of that, as long as the pointer has not really escaped the program, it is technically possible to model the heap precisely, and track the state of fields. It would be the same as tracking the state of memory on the stack as long as it doesn't escape the program.

This is also possible to do when you receive ownership of an object from an 'external' source, but then the default state you can assume for the fields is unknown. This can be further refined by ensuring they are only manipulated using some specific functions, and then you can reason more precisely about the state of the fields (either pointing to itself or to some other list_head).

This initialization on stack and move might be the way Rust does things, and it may be non-trivial to accommodate such idea of direct initialization on heap into the language rules, but that is pretty much how we're planning to make it work properly for BPF.

It will be possible to also have such 'bpf_list_head' on stack, but then you'd call an initialization helper that does the right thing, and we already precisely track the state of stack in BPF, so we know its constructed and you cannot reinitialize it.

Ofcourse, one can argue that Rust's approach is much more systematic, applies evenly to more complicated cases, and doesn't really hard code semantics of a particular implementation, etc.