[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06ae3070-0d35-df49-9310-d1fb7bfb3e67@opensuse.org>
Date: Wed, 19 Feb 2020 13:33:01 +0100
From: Michal Rostecki <mrostecki@...nsuse.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
Quentin Monnet <quentin.monnet@...ronome.com>,
Jakub Kicinski <kuba@...nel.org>,
Network Development <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Shuah Khan <shuah@...nel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH bpf-next 0/6] bpftool: Allow to select sections and filter
probes
On 2/19/20 4:02 AM, Alexei Starovoitov wrote:
> The motivation is clear, but I think the users shouldn't be made
> aware of such implementation details. I think instead of filter_in/out
> it's better to do 'full or safe' mode of probing.
> By default it can do all the probing that doesn't cause
> extra dmesgs and in 'full' mode it can probe everything.
Alright, then I will send later v2 where the "internal" implementation
(filtering out based on regex) stays similar (filter_out will stay in
the code without being exposed to users, filter_in will be removed). And
the exposed option of "safe" probing will just apply the
"(trace|write_user)" filter_out pattern. Does it sound good?
Powered by blists - more mailing lists