All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	Andrii Nakryiko <andriin@fb.com>, Yonghong Song <yhs@fb.com>,
	Martin KaFai Lau <kafai@fb.com>
Subject: Re: [PATCHv2] bpftool: Try to read btf as raw data if elf read fails
Date: Thu, 24 Oct 2019 10:54:14 -0700	[thread overview]
Message-ID: <20191024105414.65f7e323@cakuba.hsd1.ca.comcast.net> (raw)
In-Reply-To: <20191024132341.8943-1-jolsa@kernel.org>

On Thu, 24 Oct 2019 15:23:41 +0200, Jiri Olsa wrote:
> The bpftool interface stays the same, but now it's possible
> to run it over BTF raw data, like:
> 
>   $ bpftool btf dump file /sys/kernel/btf/vmlinux
>   [1] INT '(anon)' size=4 bits_offset=0 nr_bits=32 encoding=(none)
>   [2] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
>   [3] CONST '(anon)' type_id=2

My knee jerk reaction would be to implement a new keyword, like:

$ bpftool btf dump rawfile /sys/kernel/btf/vmlinux

Or such. But perhaps the auto-detection is the standard way of dealing
with different formats in the compiler world. Regardless if anyone has
an opinion one way or the other please share!!

> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> v2 changes:
>  - added is_btf_raw to find out which btf__parse_* function to call
>  - changed labels and error propagation in btf__parse_raw 
>  - drop the err initialization, which is not needed under this change

The code looks good, thanks for the changes! One question below..

> diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
> index 9a9376d1d3df..a7b8bf233cf5 100644
> --- a/tools/bpf/bpftool/btf.c
> +++ b/tools/bpf/bpftool/btf.c

> +static bool is_btf_raw(const char *file)
> +{
> +	__u16 magic = 0;
> +	int fd;
> +
> +	fd = open(file, O_RDONLY);
> +	if (fd < 0)
> +		return false;
> +
> +	read(fd, &magic, sizeof(magic));
> +	close(fd);
> +	return magic == BTF_MAGIC;

Isn't it suspicious to read() 2 bytes into an u16 and compare to a
constant like endianness doesn't matter? Quick grep doesn't reveal
BTF_MAGIC being endian-aware..

> +}
> +
>  static int do_dump(int argc, char **argv)
>  {
>  	struct btf *btf = NULL;
> @@ -465,7 +516,11 @@ static int do_dump(int argc, char **argv)
>  		}
>  		NEXT_ARG();
>  	} else if (is_prefix(src, "file")) {
> -		btf = btf__parse_elf(*argv, NULL);
> +		if (is_btf_raw(*argv))
> +			btf = btf__parse_raw(*argv);
> +		else
> +			btf = btf__parse_elf(*argv, NULL);
>  		if (IS_ERR(btf)) {
>  			err = PTR_ERR(btf);
>  			btf = NULL;


  parent reply	other threads:[~2019-10-24 17:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 13:23 [PATCHv2] bpftool: Try to read btf as raw data if elf read fails Jiri Olsa
2019-10-24 13:31 ` Jiri Olsa
2019-10-24 17:54 ` Jakub Kicinski [this message]
2019-10-25  5:01   ` Andrii Nakryiko
2019-10-25 16:31     ` Jakub Kicinski
2019-10-25 16:32       ` Jiri Olsa
2019-10-25 16:53       ` Andrii Nakryiko
2019-10-25 17:32         ` Jakub Kicinski

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=20191024105414.65f7e323@cakuba.hsd1.ca.comcast.net \
    --to=jakub.kicinski@netronome.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=yhs@fb.com \
    /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.