From owner-cvs-all@FreeBSD.ORG Sun Jul 27 13:00:26 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAAC037B401; Sun, 27 Jul 2003 13:00:26 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4180D43F75; Sun, 27 Jul 2003 13:00:14 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6RK0BV3030436; Sun, 27 Jul 2003 20:00:11 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6RK0A5H065726; Sun, 27 Jul 2003 22:00:10 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Diomidis Spinellis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 27 Jul 2003 21:34:45 +0300." <3F241B45.B5DCB079@aueb.gr> Date: Sun, 27 Jul 2003 22:00:10 +0200 Message-ID: <65725.1059336010@critter.freebsd.dk> cc: Alexander Leidinger cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: cvs-src@freebsd.org Subject: Re: 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2003 20:00:28 -0000 In message <3F241B45.B5DCB079@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@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.