On Thu, Oct 14, 2021 at 03:34:36PM +0100, Lorenz Bauer wrote:
> ---
> tools/lib/bpf/bpf.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 7d1741ceaa32..79a9bfe214b0 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -506,15 +506,14 @@ int bpf_map_delete_elem(int fd, const void *key)
>
> int bpf_map_get_next_key(int fd, const void *key, void *next_key)
> {
> - union bpf_attr attr;
> - int ret;
> + struct bpf_map_get_next_key_attr attr = {
> + .map_fd = fd,
> + .key = key,
> + .next_key = next_key,
> + };
I see this change as the main advantage of additional uapi structs.
Note, though, that such stack savings don't strictly need uapi extensions.
Light skeleton already doing that.
Every command is using exactly the right amount of stack/bytes.
The full 'union bpf_attr' is never allocated.
Take a look at bpf_gen__map_freeze() in libbpf gen_loader.c.
In case of light skeleton it's not only the stack. Saving space
in loader's map was important.
