Visualizing linux kernel datastructures

Visualizing linux kernel datastructures

[Charlemagne Lasse]

Hi,

I wanted to understand some modules in the kernel and how their data
structures are interconnected. So I am not interested in all data
structures of the kernel but something more like
net/bridge/br_private.h.

With C++ I would just tell doxygen to generate uml-like class
diagrams. But the kernel code is C and doesn't use templates. So it is
sometimes quite hard to find out what is behind a struct list_head or
an struct rb_root. Beside the missing information about the type of
objects stored in the dynamic data structure, it is also sometimes not
easy to know if a struct list_head is now an anchor for this item in a
list or if this is the root/head of the list.

So my questions would be:

1. is there a standard (machine readable?) how to correctly document
(kernel-doc?) in the code if a struct list_head is the head/root of a
list or the anchor of the item in a list?

2. is there a standard (machine readable?) how to correctly document
the type of objects stored in a list/hlist/rbtree?

3. is there already some kind of tool to visualize data structures
from the Linux kernel which supports list/hlist/rbtree and shows it in
the diagram (image, graphviz, ...) as 1:n relation?

Re: Visualizing linux kernel datastructures

[Jonathan Corbet]

On Mon, 25 Jul 2016 16:56:46 +0200
Charlemagne Lasse <charlemagnelasse@gmail.com> wrote:

> So my questions would be:
> 
> 1. is there a standard (machine readable?) how to correctly document
> (kernel-doc?) in the code if a struct list_head is the head/root of a
> list or the anchor of the item in a list?
> 
> 2. is there a standard (machine readable?) how to correctly document
> the type of objects stored in a list/hlist/rbtree?
> 
> 3. is there already some kind of tool to visualize data structures
> from the Linux kernel which supports list/hlist/rbtree and shows it in
> the diagram (image, graphviz, ...) as 1:n relation?

As far as I know, the answer to all three questions would be "no."
Confusion about such things has not generally been a problem with the
code, so there hasn't been a push for such tools (or a person motivated to
create them).

Thanks,

jon