Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Feb 2005 16:51:30 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Bosko Milekic <bmilekic@technokratis.com>
Cc:        current@freebsd.org
Subject:   Re: UFS/FFS/softupdates/snapshots: the view from 10m above
Message-ID:  <Pine.NEB.3.96L.1050208164554.18460A-100000@fledge.watson.org>
In-Reply-To: <20050208164125.GA46363@technokratis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Feb 2005, Bosko Milekic wrote:

> On Tue, Feb 08, 2005 at 10:30:58AM +0100, Poul-Henning Kamp wrote:
> > 
> > http://phk.freebsd.dk/misc/ufs.pdf
> > 
> > You need 18 sheets of paper, a color printer and some tape.
> 
>   Neat!  How'd you have this done?  Had something parse up the source?

You can find a similar picture of the sockets layer from early 2004 here: 

  http://www.watson.org/~robert/freebsd/20040303-sockets.ps

The answer to "how" is at:

  http://www.watson.org/~robert/freebsd/prcc/

That and a lot of hand-crafting and cleanup.  The first thing you find out
when trying to apply cflow and graphviz to the kernel in order to generate
a call flow diagram is that there's a lot of "stuff" and the type of
picture you want is as much a product of how you plan to use the picture
as the source you base it on.  The first thing you have to decide is
"what's important to me" and generate a list of symbols/functions/whatever
that you're not interested in.  You might or might not be interested in
memory allocation, locking, string operations, assertions, etc.  You also
find pretty quickly that you have to give graphviz a bit of help with
visual layout -- assigning ranks or groupings to functions so that you get
a representation that matches the API structure (i.e., line up the VOP's).

Another observation is that cflow doesn't do a good job at pluggable API
boundaries -- ie., protosw, VOP's, etc, so you have to give it some help
figuring out where the function pointers go.  Finally, cflow utterly barfs
on some C constructions, especially if you use prcc directly, so you may
have to help it with some macros, functions, delete the SYSINITs, etc.

That said, you get both a very useful result, and get to go through quite
an educational process generating a cohensive graph of a subsystem.  I
recommend it highly :-).  The kernel is a highly complex software system
that takes years to even start to really understand.  Graphs of this sort
are an excellent way to see how the pieces are put together.

Robert N M Watson




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050208164554.18460A-100000>