From: Stanislav Fomichev <sdf@fomichev.me>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v3 bpf-next 2/9] libbpf: introduce concept of bpf_link
Date: Fri, 28 Jun 2019 10:45:33 -0700 [thread overview]
Message-ID: <20190628174533.GI4866@mini-arch> (raw)
In-Reply-To: <CAEf4BzbB6G5jTvS+K0+0zPXWLFmAePHU2RtALogWrh7h7OV03A@mail.gmail.com>
On 06/28, Andrii Nakryiko wrote:
> On Fri, Jun 28, 2019 at 9:02 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
> >
> > On 06/27, Andrii Nakryiko wrote:
> > > bpf_link is and abstraction of an association of a BPF program and one
> > > of many possible BPF attachment points (hooks). This allows to have
> > > uniform interface for detaching BPF programs regardless of the nature of
> > > link and how it was created. Details of creation and setting up of
> > > a specific bpf_link is handled by corresponding attachment methods
> > > (bpf_program__attach_xxx) added in subsequent commits. Once successfully
> > > created, bpf_link has to be eventually destroyed with
> > > bpf_link__destroy(), at which point BPF program is disassociated from
> > > a hook and all the relevant resources are freed.
> > >
> > > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > > ---
> > > tools/lib/bpf/libbpf.c | 17 +++++++++++++++++
> > > tools/lib/bpf/libbpf.h | 4 ++++
> > > tools/lib/bpf/libbpf.map | 3 ++-
> > > 3 files changed, 23 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > index 6e6ebef11ba3..455795e6f8af 100644
> > > --- a/tools/lib/bpf/libbpf.c
> > > +++ b/tools/lib/bpf/libbpf.c
> > > @@ -3941,6 +3941,23 @@ int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
> > > return 0;
> > > }
> > >
> > > +struct bpf_link {
> > Maybe call it bpf_attachment? You call the bpf_program__attach_to_blah
> > and you get an attachment?
>
> I wanted to keep it as short as possible, bpf_attachment is way too
> long (it's also why as an alternative I've proposed bpf_assoc, not
> bpf_association, but bpf_attach isn't great shortening).
Why do you want to keep it short? We have far longer names than
bpf_attachment in libbpf. That shouldn't be a big concern.
> > > + int (*destroy)(struct bpf_link *link);
> > > +};
> > > +
> > > +int bpf_link__destroy(struct bpf_link *link)
> > > +{
> > > + int err;
> > > +
> > > + if (!link)
> > > + return 0;
> > > +
> > > + err = link->destroy(link);
> > > + free(link);
> > > +
> > > + return err;
> > > +}
> > > +
> > > enum bpf_perf_event_ret
> > > bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
> > > void **copy_mem, size_t *copy_size,
> > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > index d639f47e3110..5082a5ebb0c2 100644
> > > --- a/tools/lib/bpf/libbpf.h
> > > +++ b/tools/lib/bpf/libbpf.h
> > > @@ -165,6 +165,10 @@ LIBBPF_API int bpf_program__pin(struct bpf_program *prog, const char *path);
> > > LIBBPF_API int bpf_program__unpin(struct bpf_program *prog, const char *path);
> > > LIBBPF_API void bpf_program__unload(struct bpf_program *prog);
> > >
> > > +struct bpf_link;
> > > +
> > > +LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
> > > +
> > > struct bpf_insn;
> > >
> > > /*
> > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > > index 2c6d835620d2..3cde850fc8da 100644
> > > --- a/tools/lib/bpf/libbpf.map
> > > +++ b/tools/lib/bpf/libbpf.map
> > > @@ -167,10 +167,11 @@ LIBBPF_0.0.3 {
> > >
> > > LIBBPF_0.0.4 {
> > > global:
> > > + bpf_link__destroy;
> > > + bpf_object__load_xattr;
> > > btf_dump__dump_type;
> > > btf_dump__free;
> > > btf_dump__new;
> > > btf__parse_elf;
> > > - bpf_object__load_xattr;
> > > libbpf_num_possible_cpus;
> > > } LIBBPF_0.0.3;
> > > --
> > > 2.17.1
> > >
next prev parent reply other threads:[~2019-06-28 17:45 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 5:52 [PATCH v3 bpf-next 0/9] libbpf: add bpf_link and tracing attach APIs Andrii Nakryiko
2019-06-28 5:52 ` [PATCH v3 bpf-next 1/9] libbpf: make libbpf_strerror_r agnostic to sign of error Andrii Nakryiko
2019-06-28 19:34 ` Song Liu
2019-06-28 5:52 ` [PATCH v3 bpf-next 2/9] libbpf: introduce concept of bpf_link Andrii Nakryiko
2019-06-28 16:02 ` Stanislav Fomichev
2019-06-28 16:42 ` Andrii Nakryiko
2019-06-28 17:45 ` Stanislav Fomichev [this message]
2019-06-28 17:49 ` Alexei Starovoitov
2019-06-28 17:55 ` Stanislav Fomichev
2019-06-28 19:37 ` Song Liu
2019-06-28 5:52 ` [PATCH v3 bpf-next 3/9] libbpf: add ability to attach/detach BPF program to perf event Andrii Nakryiko
2019-06-28 16:04 ` Stanislav Fomichev
2019-06-28 16:50 ` Andrii Nakryiko
2019-06-28 17:54 ` Stanislav Fomichev
2019-06-28 17:59 ` Andrii Nakryiko
2019-06-28 18:00 ` Stanislav Fomichev
2019-06-28 18:04 ` Andrii Nakryiko
2019-06-28 18:14 ` Stanislav Fomichev
2019-06-28 18:15 ` Andrii Nakryiko
2019-06-28 18:05 ` Stanislav Fomichev
2019-06-28 5:52 ` [PATCH v3 bpf-next 4/9] libbpf: add kprobe/uprobe attach API Andrii Nakryiko
2019-06-28 19:46 ` Song Liu
2019-06-28 19:59 ` Andrii Nakryiko
2019-06-28 20:09 ` Song Liu
2019-06-28 20:34 ` Andrii Nakryiko
2019-06-28 5:52 ` [PATCH v3 bpf-next 5/9] libbpf: add tracepoint " Andrii Nakryiko
2019-06-28 19:50 ` Song Liu
2019-06-28 20:13 ` Song Liu
2019-06-28 5:53 ` [PATCH v3 bpf-next 6/9] libbpf: add raw " Andrii Nakryiko
2019-06-28 19:54 ` Song Liu
2019-06-28 5:53 ` [PATCH v3 bpf-next 7/9] selftests/bpf: switch test to new attach_perf_event API Andrii Nakryiko
2019-06-28 20:09 ` Song Liu
2019-06-28 5:53 ` [PATCH v3 bpf-next 8/9] selftests/bpf: add kprobe/uprobe selftests Andrii Nakryiko
2019-06-28 20:10 ` Song Liu
2019-06-28 5:53 ` [PATCH v3 bpf-next 9/9] selftests/bpf: convert existing tracepoint tests to new APIs Andrii Nakryiko
2019-06-28 20:13 ` Song Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190628174533.GI4866@mini-arch \
--to=sdf@fomichev.me \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.