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>