On 6/24/19 5:47 PM, Jakub Kicinski wrote: > On Tue, 25 Jun 2019 00:40:09 +0000, Alexei Starovoitov wrote: >> On 6/24/19 5:30 PM, Jakub Kicinski wrote: >>> 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. >> >> sure. I only disagreed about not touching older flags. >> --effective should be local. >> If follow up patch means 90% rewrite then revert is better. >> If it's 10% fixup then it's different story. > > I see. The local flag would not an option in getopt_long() sense, what > I was thinking was about adding an "effective" keyword: > > # bpftool -e cgroup show /sys/fs/cgroup/cgroup-test-work-dir/cg1/ > > becomes: > > # bpftool cgroup show /sys/fs/cgroup/cgroup-test-work-dir/cg1/ effective > > That's how we handle flags for update calls for instance.. > > So I think a revert :(
fair enough. removed it and force pushed bpf-next.
