public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@fb.com>, Yonghong Song <yhs@fb.com>,
	Martin Lau <kafai@fb.com>,
	bpf@vger.kernel.org, dwarves@vger.kernel.org
Subject: Re: pahole: soliciting naming suggestion for struct btf rename
Date: Thu, 14 Feb 2019 10:20:29 -0300	[thread overview]
Message-ID: <20190214132029.GA7074@kernel.org> (raw)
In-Reply-To: <20190214131156.GU3269@kernel.org>

Em Thu, Feb 14, 2019 at 10:11:56AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Feb 14, 2019 at 09:47:57AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Feb 13, 2019 at 09:43:43PM -0800, Andrii Nakryiko escreveu:
> > > happy with it. So consider this email a solicitation for naming
> > > suggestion. Keep in mind, that all the pahole's functions of the form
> > > btf__xxx will be renamed as well for consistency. If you like
> > > btf_info, let me know as well, I'll just stick with it.
> 
> > Can you try thinking if splitting this further into 'struct btf_loader',
> > 'struct btf_encoder' that would live in the pahole sources and that
> > refer to a 'struct btf' that lives in libbpf (or in libbtf, at some
> > point) is a move that eases your current needs?
> 
> So, the btf__new() in tools/lib/bpf/btf.c is basically a variant of
> btf__new() in the pahole sources, probably we should go ahead and make
> pahole use that btf__new() and do changes in tools/lib/bpf/btf.c to
> allow for it to access internal state that it needs to do its job?

No, we can't, because tools/lib/btf/btf.c btf__new() is centered on
getting some BTF buffer no matter where it comes from and passing it to
the kernel.

So probably we should backtrack to my previous suggestion of having
pahole use 'struct btf_loader', or even more explicitely, 'struct
btf_elf' to make extra clear that this has nothing to do with the
kernel, its purely about loading/encoding the BTF info from/to a ELF
file.

- Arnaldo

  reply	other threads:[~2019-02-14 13:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14  5:43 pahole: soliciting naming suggestion for struct btf rename Andrii Nakryiko
2019-02-14 12:47 ` Arnaldo Carvalho de Melo
2019-02-14 13:11   ` Arnaldo Carvalho de Melo
2019-02-14 13:20     ` Arnaldo Carvalho de Melo [this message]
2019-02-14 14:01       ` Arnaldo Carvalho de Melo
2019-02-15  4:37         ` Andrii Nakryiko
2019-02-15 17:15           ` Arnaldo Carvalho de Melo
2019-02-15 17:25             ` Andrii Nakryiko
2019-02-15 17:43               ` Arnaldo Carvalho de Melo
2019-02-15 17:17   ` Alexei Starovoitov
2019-02-15 17:25     ` Arnaldo Carvalho de Melo
2019-02-15 18:47       ` Alexei Starovoitov
2019-02-15 20:21         ` Daniel Borkmann
2019-02-18 12:44           ` Arnaldo Carvalho de Melo

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=20190214132029.GA7074@kernel.org \
    --to=acme@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=kafai@fb.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox