cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c

[Poul-Henning Kamp]

In message <3F241B45.B5DCB079 at aueb.gr>, Diomidis Spinellis writes:

>I've been closely following the discussion from its beginning thinking
>about such opportunities.  Up to now I've applied CScout on a couple of
>userland programs; maybe I should concentrate on the kernel.

Actually, I guess userland may be in more need than the kernel, since
we have people who are all over the kernel, whereas most of userland
is rarely worked on at all.

>Let me provide you with some details on the tools Microsoft develops and
>uses internally on their Windows code.  Their code may be behind FreeBSD
>in terms of cohesion and stability, but the tools appear impressive. 

Yes, indeed.

(Sorry for the length of this)

The thing which grinds in my ear about most of the tools I have ever
heard about is "specially annotated source code" or "model reflecting
the structure of the program" and similar.

I personally don't want to have to express the same ting multiple
times, once for the compiler and once for each interested tool is
N-1 times too many.

This is not the same as I don't think it will be necessary to add
more information than we currently record, in order for tools of
this kind to be useful, but I don't want there to be a chance for
the two representations of the same information to get out of sync.

Ideally, I would prefer to program in a language where I am able
to express my full intent inside the language, without resorting
to "out of band" communications.  (No, neither Ada, C++ nor LISP
is that language).

One of the things I liked about primitive programming languages
like FORTRAN and RPG-II was that having a notion of columns in
the source code, it was possible to add a single character field
per line for conveying optimization priority.  One particular
FORTRAN compiler used column 100 to split the statements into
5 classes of optimization priority, and this allowed me to communicate
information about the programs nature to the compiler which it
could put to good use during compilation.

The C language with its free flowing format does not lend itself to
the same sort of things and therefore adding information very
rapidly defaces the much hailed clarity of the language:


	if (p == NULL) { __attribute__((unlikely));
		foo;
	} else {
		bar;
	}

Conveys no simple graphical clue to the programmer until we teach
the editor to start to do a Warhol on the source code.

So I do not think we are looking at a simple "Do The Right Think"
solution, and even with a capacity as dds@ on board, I am afraid
that we may still merely be dipping our toes rather than take a
full swim.  (I'll be more than happy to be told that I am totally
wrong and that parsing and analying C source is piece of cake for
people who know how to)

Lacking these big tools, I am happy to see even small tools which
can make a difference simply by presenting the already available
information in a different way or format.  To see what I mean:

	cd /usr/src/tools/tools/vop_table
	chmod 755 vop_table.tcl
	./vop_table.tcl
	point your broswer at _.html

	(or see http://phk.freebsd.dk/misc/vop.html )

This table is not much use unless you know a bit out our VOP_
operations, but if you have a clue about VOP operations, this table
tells you at a glance that the sync_vnode and swapdev_vnode are
highly irregular, and that the nfsv2 vnodeops do not follow our
naming scheme for vnode operations.  To somebody contemplating any
sort of VOP hacking, the table offers an instant overview of the
amount of affected code.

Remember, programs are just data, and data can be mined, analyzed
and presented just as well as budgets.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.