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. Takshak, could you check which way is cleaner? Revert and new patch or follow up fix? But bpftool doesn't have a way to do local, no? so it's kinda new feature and other flags should become local too. hence it feels more like follow up. Just my .02
