From: Song Liu <songliubraving@fb.com>
To: Okash Khawaja <osk@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>, Martin Lau <kafai@fb.com>,
"Alexei Starovoitov" <ast@kernel.org>, Yonghong Song <yhs@fb.com>,
Quentin Monnet <quentin.monnet@netronome.com>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
"David S. Miller" <davem@davemloft.net>,
Networking <netdev@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/3] bpf: btf: export btf types and name by offset from lib
Date: Wed, 20 Jun 2018 23:24:00 +0000 [thread overview]
Message-ID: <599DC237-386E-495A-B205-2C76A7AFEDFF@fb.com> (raw)
In-Reply-To: <20180620224849.GA18488@w1t1fb>
> On Jun 20, 2018, at 3:48 PM, Okash Khawaja <osk@fb.com> wrote:
>
> On Wed, Jun 20, 2018 at 11:40:19PM +0100, Song Liu wrote:
>>
>>
>>> On Jun 20, 2018, at 1:30 PM, Okash Khawaja <osk@fb.com> wrote:
>>>
>>> This patch introduces btf__resolve_type() function and exports two
>>> existing functions from libbpf. btf__resolve_type follows modifier
>>> types like const and typedef until it hits a type which actually takes
>>> up memory, and then returns it. This function follows similar pattern
>>> to btf__resolve_size but instead of computing size, it just returns
>>> the type.
>>>
>>> These functions will be used in the followig patch which parses
>>> information inside array of `struct btf_type *`. btf_name_by_offset is
>>> used for printing variable names.
>>>
>>> Signed-off-by: Okash Khawaja <osk@fb.com>
>>> Acked-by: Martin KaFai Lau <kafai@fb.com>
>>>
>>> ---
>>> tools/lib/bpf/btf.c | 65 ++++++++++++++++++++++++++++++++++++----------------
>>> tools/lib/bpf/btf.h | 3 ++
>>> 2 files changed, 48 insertions(+), 20 deletions(-)
>>>
>>> --- a/tools/lib/bpf/btf.c
>>> +++ b/tools/lib/bpf/btf.c
>>> @@ -17,6 +17,11 @@
>>>
>>> #define BTF_MAX_NR_TYPES 65535
>>>
>>> +#define IS_MODIFIER(k) (((k) == BTF_KIND_TYPEDEF) || \
>>> + ((k) == BTF_KIND_VOLATILE) || \
>>> + ((k) == BTF_KIND_CONST) || \
>>> + ((k) == BTF_KIND_RESTRICT))
>>> +
>>> static struct btf_type btf_void;
>>>
>>> struct btf {
>>> @@ -33,14 +38,6 @@ struct btf {
>>> int fd;
>>> };
>>>
>>> -static const char *btf_name_by_offset(const struct btf *btf, uint32_t offset)
>>> -{
>>> - if (offset < btf->hdr->str_len)
>>> - return &btf->strings[offset];
>>> - else
>>> - return NULL;
>>> -}
>>> -
>>> static int btf_add_type(struct btf *btf, struct btf_type *t)
>>> {
>>> if (btf->types_size - btf->nr_types < 2) {
>>> @@ -190,15 +187,6 @@ static int btf_parse_type_sec(struct btf
>>> return 0;
>>> }
>>>
>>> -static const struct btf_type *btf_type_by_id(const struct btf *btf,
>>> - uint32_t type_id)
>>> -{
>>> - if (type_id > btf->nr_types)
>>> - return NULL;
>>> -
>>> - return btf->types[type_id];
>>> -}
>>
>> nit: Why do we need to move these two functions to later of the file?
> No real reason. It looked like this file was following a convention of
> keeping statics together. I'll put them back in place if no one objects.
I see. Let's keep this patch as-is then.
Thanks,
Song
>
>>
>> Other than this,
>>
>> Acked-by: Song Liu <songliubraving@fb.com>
> Thanks
>
>>
>>> -
>>> static bool btf_type_is_void(const struct btf_type *t)
>>> {
>>> return t == &btf_void || BTF_INFO_KIND(t->info) == BTF_KIND_FWD;
>>> @@ -234,7 +222,7 @@ int64_t btf__resolve_size(const struct b
>>> int64_t size = -1;
>>> int i;
>>>
>>> - t = btf_type_by_id(btf, type_id);
>>> + t = btf__type_by_id(btf, type_id);
>>> for (i = 0; i < MAX_RESOLVE_DEPTH && !btf_type_is_void_or_null(t);
>>> i++) {
>>> size = btf_type_size(t);
>>> @@ -259,7 +247,7 @@ int64_t btf__resolve_size(const struct b
>>> return -EINVAL;
>>> }
>>>
>>> - t = btf_type_by_id(btf, type_id);
>>> + t = btf__type_by_id(btf, type_id);
>>> }
>>>
>>> if (size < 0)
>>> @@ -271,6 +259,26 @@ int64_t btf__resolve_size(const struct b
>>> return nelems * size;
>>> }
>>>
>>> +int32_t btf__resolve_type(const struct btf *btf, uint32_t type_id)
>>> +{
>>> + const struct btf_type *t;
>>> + int depth = 0;
>>> +
>>> + t = btf__type_by_id(btf, type_id);
>>> + while (depth < MAX_RESOLVE_DEPTH &&
>>> + !btf_type_is_void_or_null(t) &&
>>> + IS_MODIFIER(BTF_INFO_KIND(t->info))) {
>>> + type_id = t->type;
>>> + t = btf__type_by_id(btf, type_id);
>>> + depth++;
>>> + }
>>> +
>>> + if (depth == MAX_RESOLVE_DEPTH || btf_type_is_void_or_null(t))
>>> + return -EINVAL;
>>> +
>>> + return type_id;
>>> +}
>>> +
>>> int32_t btf__find_by_name(const struct btf *btf, const char *type_name)
>>> {
>>> uint32_t i;
>>> @@ -280,7 +288,7 @@ int32_t btf__find_by_name(const struct b
>>>
>>> for (i = 1; i <= btf->nr_types; i++) {
>>> const struct btf_type *t = btf->types[i];
>>> - const char *name = btf_name_by_offset(btf, t->name_off);
>>> + const char *name = btf__name_by_offset(btf, t->name_off);
>>>
>>> if (name && !strcmp(type_name, name))
>>> return i;
>>> @@ -371,3 +379,20 @@ int btf__fd(const struct btf *btf)
>>> {
>>> return btf->fd;
>>> }
>>> +
>>> +const char *btf__name_by_offset(const struct btf *btf, uint32_t offset)
>>> +{
>>> + if (offset < btf->hdr->str_len)
>>> + return &btf->strings[offset];
>>> + else
>>> + return NULL;
>>> +}
>>> +
>>> +const struct btf_type *btf__type_by_id(const struct btf *btf,
>>> + uint32_t type_id)
>>> +{
>>> + if (type_id > btf->nr_types)
>>> + return NULL;
>>> +
>>> + return btf->types[type_id];
>>> +}
>>> --- a/tools/lib/bpf/btf.h
>>> +++ b/tools/lib/bpf/btf.h
>>> @@ -17,6 +17,9 @@ void btf__free(struct btf *btf);
>>> struct btf *btf__new(uint8_t *data, uint32_t size, btf_print_fn_t err_log);
>>> int32_t btf__find_by_name(const struct btf *btf, const char *type_name);
>>> int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id);
>>> +int32_t btf__resolve_type(const struct btf *btf, uint32_t type_id);
>>> int btf__fd(const struct btf *btf);
>>> +const char *btf__name_by_offset(const struct btf *btf, uint32_t offset);
>>> +const struct btf_type *btf__type_by_id(const struct btf *btf, uint32_t type_id);
>>>
>>> #endif
next prev parent reply other threads:[~2018-06-20 23:24 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 20:30 [PATCH bpf-next 0/3] bpf: btf: json print btf info with bpftool map dump Okash Khawaja
2018-06-20 20:30 ` [PATCH bpf-next 1/3] bpf: btf: export btf types and name by offset from lib Okash Khawaja
2018-06-20 22:40 ` Song Liu
2018-06-20 22:48 ` Okash Khawaja
2018-06-20 23:24 ` Song Liu [this message]
2018-06-20 20:30 ` [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality Okash Khawaja
2018-06-20 23:14 ` Song Liu
2018-06-21 10:31 ` Okash Khawaja
2018-06-21 10:42 ` Quentin Monnet
2018-06-22 10:24 ` Okash Khawaja
2018-06-22 10:39 ` Quentin Monnet
2018-06-22 18:44 ` Jakub Kicinski
2018-06-21 21:59 ` Jakub Kicinski
2018-06-21 22:51 ` Martin KaFai Lau
2018-06-21 23:07 ` Jakub Kicinski
2018-06-21 23:58 ` Martin KaFai Lau
2018-06-22 0:25 ` Jakub Kicinski
2018-06-22 1:20 ` Martin KaFai Lau
2018-06-22 11:17 ` Okash Khawaja
2018-06-22 18:43 ` Jakub Kicinski
2018-06-22 18:40 ` Jakub Kicinski
2018-06-22 20:58 ` Martin KaFai Lau
2018-06-22 21:27 ` Jakub Kicinski
2018-06-22 21:49 ` Jakub Kicinski
2018-06-22 23:19 ` Martin KaFai Lau
2018-06-22 23:40 ` Jakub Kicinski
2018-06-22 23:58 ` Martin KaFai Lau
2018-06-22 22:48 ` Okash Khawaja
2018-06-22 22:54 ` Martin KaFai Lau
2018-06-22 23:32 ` Jakub Kicinski
2018-06-23 0:26 ` Martin KaFai Lau
2018-06-26 16:48 ` Okash Khawaja
2018-06-26 20:31 ` Jakub Kicinski
2018-06-26 22:27 ` Martin KaFai Lau
2018-06-26 22:35 ` Jakub Kicinski
2018-06-27 10:34 ` Daniel Borkmann
2018-06-27 11:47 ` Okash Khawaja
2018-06-27 12:56 ` Daniel Borkmann
2018-07-01 10:31 ` Okash Khawaja
2018-07-02 17:19 ` Jakub Kicinski
2018-06-20 20:30 ` [PATCH bpf-next 3/3] bpf: btf: json print map dump with btf info Okash Khawaja
2018-06-20 23:22 ` Song Liu
2018-06-21 10:05 ` Okash Khawaja
2018-06-21 10:24 ` Quentin Monnet
2018-06-21 14:26 ` Okash Khawaja
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=599DC237-386E-495A-B205-2C76A7AFEDFF@fb.com \
--to=songliubraving@fb.com \
--cc=Kernel-team@fb.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jakub.kicinski@netronome.com \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=osk@fb.com \
--cc=quentin.monnet@netronome.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
Powered by JetHome