On Mon, Mar 2, 2015 at 4:26 AM, Daniel Borkmann wrote:
> On 03/02/2015 12:51 PM, Masami Hiramatsu wrote:
>> (2015/03/02 20:10), Daniel Borkmann wrote:
>>>
>>> Well, currently all possible map types (hash table, array map) that
>>> would actually call into bpf_register_map_type() are only built whe
On 03/02/2015 12:51 PM, Masami Hiramatsu wrote:
> (2015/03/02 20:10), Daniel Borkmann wrote:
>> On 03/02/2015 11:53 AM, Masami Hiramatsu wrote:
>> ...
>>> Hmm, it seems that this still doesn't hide some APIs which is provided
>>> only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
(2015/03/02 20:10), Daniel Borkmann wrote:
> On 03/02/2015 11:53 AM, Masami Hiramatsu wrote:
> ...
>> Hmm, it seems that this still doesn't hide some APIs which is provided
>> only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
>> I think all those APIs should be hidden in #ifdef o
On 03/02/2015 11:53 AM, Masami Hiramatsu wrote:
...
> Hmm, it seems that this still doesn't hide some APIs which is provided
> only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
> I think all those APIs should be hidden in #ifdef or at least be commented
> so that the user doesn't
(2015/03/02 8:27), Alexei Starovoitov wrote:
> From: Daniel Borkmann
>
> Socket filter code and other subsystems with upcoming eBPF support should
> not need to deal with the fact that we have CONFIG_BPF_SYSCALL defined or
> not.
>
> Having the bpf syscall as a config option is a nice thing and
From: Daniel Borkmann
Socket filter code and other subsystems with upcoming eBPF support should
not need to deal with the fact that we have CONFIG_BPF_SYSCALL defined or
not.
Having the bpf syscall as a config option is a nice thing and I'd expect
it to stay that way for expert users (I presume
6 matches
Mail list logo
