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 :( > 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
