On Fri, Aug 9, 2019 at 2:48 PM Daniel Xu <d...@dxuuu.xyz> wrote:
>
> It is sometimes necessary to perform ioctl's on the underlying perf fd.
> There is not currently a way to extract the fd given a bpf_link, so add a
> a pair of casting and getting helpers.
>
> The casting and getting helpers are nice because they let us define
> broad categories of links that makes it clear to users what they can
> expect to extract from what type of link.
>
> Signed-off-by: Daniel Xu <d...@dxuuu.xyz>
> ---
> tools/lib/bpf/libbpf.c | 19 +++++++++++++++++++
> tools/lib/bpf/libbpf.h | 8 ++++++++
> tools/lib/bpf/libbpf.map | 6 ++++++
> 3 files changed, 33 insertions(+)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index ead915aec349..f4d750863abd 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -4004,6 +4004,25 @@ static int bpf_link__destroy_perf_event(struct
> bpf_link *link)
> return err;
> }
>
> +const struct bpf_link_fd *bpf_link__as_fd(const struct bpf_link *link)
> +{
> + if (!link)
> + return NULL;
I'm not sure about all those NULL checks everywhere. It's not really a
Java, passing NULL is ok only to xxx__free() kind of functions,
everything else shouldn't expect to deal with NULLs correctly, IMO.
> +
> + if (link->destroy != &bpf_link__destroy_perf_event)
While this is clever, it doesn't handle case for raw tracepoint
already. It is also anti-future proof, as when we add another use case
for bpf_link__fd with different destroy callback, we'll most probably
forget to update this function.
So let's instead introduce enum bpf_link_type and make it standard
part of "abstract" bpf_link. Please also add getter
enum bpf_link_type bpf_link__type(const struct bpf_link *link)
{
return link->type;
}
to fetch it. That way users will also be able to write generic
functions potentially handling multiple kinds of bpf_links (and there
won't be a need to just "guess" the type of bpf_link).
> + return NULL;
> +
> + return (struct bpf_link_fd *)link;
> +}
> +
> +int bpf_link_fd__fd(const struct bpf_link_fd *link)
> +{
> + if (!link)
> + return -1;
> +
> + return link->fd;
> +}
> +
> struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
> int pfd)
> {
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 8a9d462a6f6d..4498b6ae459a 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -166,6 +166,14 @@ 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;
> +struct bpf_link_fd;
> +
> +/* casting APIs */
> +LIBBPF_API const struct bpf_link_fd *
> +bpf_link__as_fd(const struct bpf_link *link);
> +
> +/* getters APIs */
> +LIBBPF_API int bpf_link_fd__fd(const struct bpf_link_fd *link);
But otherwise these new APIs look great, thanks!
>
> LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
>
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index f9d316e873d8..b58dd0f0259c 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -184,3 +184,9 @@ LIBBPF_0.0.4 {
> perf_buffer__new_raw;
> perf_buffer__poll;
> } LIBBPF_0.0.3;
> +
> +LIBBPF_0.0.5 {
> + global:
> + bpf_link__as_fd;
> + bpf_link_fd__fd;
> +} LIBBPF_0.0.4;
> --
> 2.20.1
>
