lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 9 May 2020 22:06:45 -0700
From:   Yonghong Song <>
To:     Alexei Starovoitov <>
CC:     Andrii Nakryiko <>, <>,
        Martin KaFai Lau <>, <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>, <>
Subject: Re: [PATCH bpf-next v4 16/21] tools/libbpf: add bpf_iter support

On 5/9/20 5:35 PM, Alexei Starovoitov wrote:
> On Sat, May 09, 2020 at 10:59:17AM -0700, Yonghong Song wrote:
>> @@ -6891,6 +6897,7 @@ static int bpf_object__collect_st_ops_relos(struct bpf_object *obj,
>>   #define BTF_TRACE_PREFIX "btf_trace_"
>>   #define BTF_LSM_PREFIX "bpf_lsm_"
>> +#define BTF_ITER_PREFIX "__bpf_iter__"
>>   #define BTF_MAX_NAME_SIZE 128
> In the kernel source the prefix doesn't stand out, but on libbpf side it looks
> inconsistent. May be drop __ prefix and keep one _ in the suffix?

Currently, I have context type as
    struct bpf_iter__bpf_map
Based on the above proposal, we will have function name as
It is quite similar to each other. My current usage to have
intends to make func name and struct type name quite different.
Or maybe
     bpf_iter__bpf_map vs. bpf_iter_bpf_map
just fine as user should not care about func name
bpf_iter_bpf_map at all?

Powered by blists - more mailing lists