Is there a way to build a cross reference with kernel file

Javier Martinez Canillas martinez.javier at gmail.com
Fri Dec 16 21:04:17 EST 2011


On Sat, Dec 17, 2011 at 1:58 AM, Jeff Haran <jharan at bytemobile.com> wrote:
>> -----Original Message-----
>> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
>> bounces at kernelnewbies.org] On Behalf Of Alexandre Courbot
>> Sent: Monday, October 24, 2011 7:05 PM
>> To: Jimmy Pan
>> Cc: Kernelnewbies at kernelnewbies.org
>> Subject: Re: Is there a way to build a cross reference with kernel
> file
>>
>> On Tue, Oct 25, 2011 at 12:00 AM, Jimmy Pan <dspjm1 at gmail.com> wrote:
>> > It seems we can use ctags, while, I don't really know how to
> implement it.
>> > I don't want to use the online cross reference every time...
>>
>> I personally use KDevelop to navigate the kernel. It's not perfect yet
>> and a little bit tricky to configure correctly, but it's still pretty
>> efficient and I work on improving it. I wrote about it recently:
>> http://www.gnurou.org/code/kdevelop-kernel
>>
>> CTags is also known to work well, actually there is even a 'make tags'
>> target in the kernel's Makefile.
>>
>> Hope this helps,
>> Alex.
>
> I have found that one of the hardest things to deal with when trying to
> understand kernel code (or the code for any big project written in C) is
> trying to find out where a given structure field is used. For instance,
> say you want to find out where the cb field of a sk_buff structure is
> referenced. If I use cscope on my kernel source tree and enter "cb"
> under "Find this C symbol:", it provides 2596 references. The vast
> majority of those references will have nothing to do with sk_buff
> structures because cb is used as a variable or field name all over the
> place, usually to mean some sort of pointer to a callback function, but
> I'd have to sift through all 2596 of them to find the references to the
> "right" cb.
>
> I tried kdevelop to solve this same problem. It doesn't seem to provide
> any references to structure field names. Hover the mouse cursor over a
> field name in kdevelop and nothing pops up like it would for say a local
> or global variable name. At least it didn't when I tried it.
>
> Has anybody found a tool the solves this kind of problem well?
> Specifically, given a struct foo containing a field named bar, show me
> all of the code that references the bar field of struct foos but not the
> bar fields of other structures nor instances of variables that are
> themselves named bar.
>
> I realize that with things like arbitrary type casting and the C
> pre-processor, doing this kind of thing with 100% accuracy could be
> quite difficult. But even if it was only partially successful at
> eliminating the false positives that come with tools like cscope, it
> could save a lot of time.
>

Well you can always rely on conventions. For the sk_buff example,
generally the kernel uses sk_buff pointers and the variable name is
almost always skb. So git grep skb->cb is a good approach to this.

Also, I think that the first thing one have to learn in the kernel is
the project layout. Where everything is placed and why. I recommend
that the first thing someone getting into kernel dev is getting
familiar with each sub-dir.

One should be able to ask questions such as: Where are the input
drivers? Where is the code for a given filesystem or the support for
an architecture?

So, in your example I would do something like this:

$ git grep "skb->cb" net/

If I want to know the usage of that field in the network core or

$ git grep "skb->cb" drivers/net/

If I want to know how drivers used it.

Again, ETAGS and tools like that are good for pointing where a symbol
is defined, but its usage is a little more trickier. Like you said the
kernel uses _lots_ of functions pointers so I don't think that a tool
that shows me every place a given function is called will be easier
(if possible) to implement.

Hope it helps,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain



More information about the Kernelnewbies mailing list