On 2/16/24 08:52, Andrii Nakryiko wrote:
@@ -487,6 +487,14 @@ struct bpf_struct_ops {
* from "data".
*/
void *kern_vdata;
+ /* Description of the layout that a shadow copy should look like.
+ */
+ const struct bpf_struct_ops_map_info *shadow_info;
+ /* A shadow copy of the struct_ops data created according to the
+ * layout described by shadow_info.
+ */
+ void *shadow_data;
+ __u32 shadow_data_size;
what I mentioned on cover letter, just a few lines above, before
kern_vdata we have just `void *data` which initially contains whatever
was set in ELF. Just expose that through bpf_map__initial_value() and
teach bpftool to generate section with variables for that memory and
that should be all we need, no?
I am not sure if read your question correctly.
Padding & alignments can vary in different platforms. BPF and
user space programs are supposed to be in different platforms.
So, I can not expect that the same struct has the same layout in
BPF/x86/and ARM, right?
We can constraint this functionality to 64-bit host architectures, and
then all these concerns will go away. It should be possible to make
all this work even if the host architecture is 64-bit, but I'm not
sure it's worth doing.
Either way, we need to keep this simple and minimal, no extra
descriptors and stuff like that.
Ok! I will make changes in the next version base on the assumption that
the host architecture is compatible with BPF.
