Messages in this thread | | | Date | Fri, 28 Dec 2012 14:07:34 +0100 | From | Borislav Petkov <> | Subject | Re: how to look for source code in kernel |
| |
On Thu, Dec 27, 2012 at 11:36:13PM -0800, Eric W. Biederman wrote: > git-ls-files | xargs fgrep 'struct f2fs_inode' > > That returns instantly and tells me where to look. If you can do an > instant brute force search what is the point of an index?
Not if you're using a lame-ass laptop with a rotating disk:
$ time git ls-files | xargs grep -E 'struct mce\W*{' arch/x86/include/uapi/asm/mce.h:struct mce { arch/x86/kernel/cpu/mcheck/mce.c: if (!final || memcmp(m, final, sizeof(struct mce))) {
real 2m48.415s user 0m2.388s sys 0m15.668s
What I've grown accustomed to is cscope with a prior find run on the kernel source tree to create a custom cscope.files which cscope uses to index and then using vim bindings in cscope so that if, for example, the cursor is on a function call, executing a keyboard shortcut opens the definition of that function in another vim tab. I.e., a thin IDE done right.
> My experience with gui editors is that they always hide something I > need to see, or my code is just strange enough (say having asm file, > or supporting multiple architectures) that the tools get horribly > confused.
That's true, then I tend to use another xterm with tabbed vim showing additional files. Btw, git ls-files assumes a source file is tracked by git and in the seldom case where you're adding new, yet untracked files, that won't work.
So probably a mixed approach of cscope in one window and grep + editor in another would cover all bases. For a newbie who wants to only browse the code, cscope should be enough for starters, I'd say.
Thanks.
-- Regards/Gruss, Boris.
| |