On 2/19/20 5:52 PM, Daniel Borkmann wrote: > On 2/19/20 5:37 PM, Alexei Starovoitov wrote: >> On Wed, Feb 19, 2020 at 4:33 AM Michal Rostecki >> <mrostecki@xxxxxxxxxxxx> wrote: >>> >>> 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? >> >> yes. If implementation is doing filter_in and applying >> 'trace_printk|write_user' >> strings hidden within bpftool than I think it should be good. >> What do you think the default should be? >> It feels to me that the default should not be causing dmesg prints. >> So only addition flag for bpftool command line will be 'bpftool >> feature probe full' > > Agree, that makes sense to me. Makes sense to me as well. I will do that in v2.
