Re: [RFC bpf-next v2 1/3] libbpf: Create a shadow copy for each struct_ops map if necessary.

[Kui-Feng Lee <sinquersw@gmail.com>]

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.