[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180509152057.2aeae80f@cakuba.netronome.com>
Date: Wed, 9 May 2018 15:20:57 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Martin KaFai Lau <kafai@...com>, Alexei Starovoitov <ast@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Andrey Ignatov <rdna@...com>
Cc: <netdev@...r.kernel.org>, <kernel-team@...com>,
David Beckett <david.beckett@...ronome.com>
Subject: Re: libbpf backward compatibility (was: [PATCH bpf-next v5 09/10]
bpf: btf: Add BTF support to libbpf)
On Wed, 9 May 2018 15:17:12 -0700, Jakub Kicinski wrote:
> On Wed, 18 Apr 2018 15:56:05 -0700, Martin KaFai Lau wrote:
> > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> > index 39f6a0d64a3b..01bda076310f 100644
> > --- a/tools/lib/bpf/bpf.h
> > +++ b/tools/lib/bpf/bpf.h
> > @@ -26,6 +26,20 @@
> > #include <linux/bpf.h>
> > #include <stddef.h>
> >
> > +struct bpf_create_map_attr {
> > + const char *name;
> > + enum bpf_map_type map_type;
> > + __u32 map_flags;
> > + __u32 key_size;
> > + __u32 value_size;
> > + __u32 max_entries;
> > + __u32 numa_node;
> > + __u32 btf_fd;
> > + __u32 btf_key_id;
> > + __u32 btf_value_id;
> > +};
> > +
> > +int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr);
> > int bpf_create_map_node(enum bpf_map_type map_type, const char *name,
> > int key_size, int value_size, int max_entries,
> > __u32 map_flags, int node);
> > @@ -87,4 +101,6 @@ int bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32 *info_len);
> > int bpf_prog_query(int target_fd, enum bpf_attach_type type, __u32 query_flags,
> > __u32 *attach_flags, __u32 *prog_ids, __u32 *prog_cnt);
> > int bpf_raw_tracepoint_open(const char *name, int prog_fd);
> > +int bpf_load_btf(void *btf, __u32 btf_size, char *log_buf, __u32 log_buf_size,
> > + bool do_log);
> > #endif
>
> Does libbpf have to provide backward compatibility? Are the function
> prototypes not supposed to change?
>
> Recently a number of *_xattr functions were added, these are nice for
> limiting the number of parameters passed to functions, but they don't
> buy us anything in terms of extensibility unless we can grow the
> structures. Should structure size be passed in as one of parameters?
Or is the backward compatibility not at the binary level so we can grow
the structures at will?
Powered by blists - more mailing lists