lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 4 Oct 2019 07:36:59 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...com>,
        Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next] libbpf: Add cscope and TAGS targets to Makefile

On Fri, Oct 4, 2019 at 2:27 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@...il.com> writes:
>
> > On Thu, Oct 3, 2019 at 1:46 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> >>
> >> Using cscope and/or TAGS files for navigating the source code is useful.
> >> Add simple targets to the Makefile to generate the index files for both
> >> tools.
> >>
> >> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
> >> ---
> >
> > Thanks a lot for adding this!
> >
> > I tested cscope only and it works (especially without -k), so:
> >
> > Tested-by: Andrii Nakryiko <andriin@...com>
> >
> >
> >>  tools/lib/bpf/.gitignore |  2 ++
> >>  tools/lib/bpf/Makefile   | 10 +++++++++-
> >>  2 files changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/lib/bpf/.gitignore b/tools/lib/bpf/.gitignore
> >> index d9e9dec04605..c1057c01223e 100644
> >> --- a/tools/lib/bpf/.gitignore
> >> +++ b/tools/lib/bpf/.gitignore
> >> @@ -3,3 +3,5 @@ libbpf.pc
> >>  FEATURE-DUMP.libbpf
> >>  test_libbpf
> >>  libbpf.so.*
> >> +TAGS
> >> +cscope.*
> >> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> >> index c6f94cffe06e..57df6b933196 100644
> >> --- a/tools/lib/bpf/Makefile
> >> +++ b/tools/lib/bpf/Makefile
> >> @@ -262,7 +262,7 @@ clean:
> >>
> >>
> >>
> >> -PHONY += force elfdep bpfdep
> >> +PHONY += force elfdep bpfdep cscope TAGS
> >>  force:
> >>
> >>  elfdep:
> >> @@ -271,6 +271,14 @@ elfdep:
> >>  bpfdep:
> >>         @if [ "$(feature-bpf)" != "1" ]; then echo "BPF API too old"; exit 1 ; fi
> >>
> >> +cscope:
> >> +       (echo \-k; echo \-q; for f in *.c *.h; do echo $$f; done) > cscope.files
> >> +       cscope -b -f cscope.out
> >
> > 1. I'd drop -k, given libbpf is user-land library, so it's convenient
> > to jump into system headers for some of BPF definitions.
>
> Well, the reason I included it was that when using the version in the
> kernel tree, I found it really annoying to jump to kernel headers
> installed in the system. Then I'd rather the jump fails and I can go
> lookup the header in the kernel tree myself.
>
> So maybe we should rather use -I to point at the parent directory? You
> guys could then strip that when syncing to the github repo?

-I will allow to jump into kernel repo includes, right? That would be
even better!

>
> > 2. Wouldn't this be simpler and work exactly the same?
> >
> > ls *.c *.h > cscope.files
> > cscope -b -q -f cscope.out
>
> Well, I usually avoid 'ls' because I have it aliased in my shell so it
> prints more info than just the file names. But I don't suppose that's an
> issue inside the Makefile, so will fix :)
>
> >> +
> >> +TAGS:
> >
> > let's make it lower-case, please? Linux makefile supports both `make
> > tags` and `make TAGS`, but all-caps is terrible :)
>
> You mean just rename the 'make' target, right? Sure, can do...
>
> As for the file itself, I think the version actually on what you use to
> generate the tags file. 'ctags' generates lower-case 'tags' by default,
> while 'etags' generates 'TAGS'.
>
> I don't use either, so dunno why that different exists, and if it's
> actually meaningful? Should we do both?

Me neither, but yeah, I was referring to `make tags` target only.

>
> >> +       rm -f TAGS
> >> +       echo *.c *.h | xargs etags -a
> >
> > nit: might as well do ls *.c *.h for consistency with cscope
> > suggestion above (though in both cases we just rely on shell expansion
> > logic, so doesn't matter).
>
> Heh, pedantic much? ;)
> But OK, I have no strong feelings one way or the other...
>

Guilty as charged :) Thanks!

> -Toke
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ