[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190624173005.06430163@cakuba.netronome.com>
Date: Mon, 24 Jun 2019 17:30:05 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Alexei Starovoitov <ast@...com>
Cc: Andrey Ignatov <rdna@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Takshak Chahande <ctakshak@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"ast@...nel.org" <ast@...nel.org>,
Kernel Team <Kernel-team@...com>,
Stanislav Fomichev <sdf@...gle.com>
Subject: Re: [PATCH bpf-next] bpftool: Add BPF_F_QUERY_EFFECTIVE support in
bpftool cgroup [show|tree]
On Tue, 25 Jun 2019 00:21:57 +0000, Alexei Starovoitov wrote:
> On 6/24/19 5:16 PM, Jakub Kicinski wrote:
> > On Mon, 24 Jun 2019 23:38:11 +0000, Alexei Starovoitov wrote:
> >> I don't think this patch should be penalized.
> >> I'd rather see we fix them all.
> >
> > So we are going to add this broken option just to remove it?
> > I don't understand.
> > I'm happy to spend the 15 minutes rewriting this if you don't
> > want to penalize Takshak.
>
> hmm. I don't understand the 'broken' part.
> The only issue I see that it could have been local vs global,
> but they all should have been local.
I don't think all of them. Only --mapcompat and --bpffs. bpffs could
be argued. On mapcompat I must have not read the patch fully, I was
under the impression its a global libbpf flag :(
--json, --pretty, --nomount, --debug are global because they affect
global behaviour of bpftool. The difference here is that we basically
add a syscall parameter as a global option.
Powered by blists - more mailing lists