From owner-freebsd-hackers  Fri May 22 14:56:53 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA27000
          for freebsd-hackers-outgoing; Fri, 22 May 1998 14:56:53 -0700 (PDT)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from ns1.yes.no (ns1.yes.no [195.119.24.10])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26991
          for <hackers@FreeBSD.ORG>; Fri, 22 May 1998 14:56:44 -0700 (PDT)
          (envelope-from eivind@bitbox.follo.net)
Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218])
	by ns1.yes.no (8.8.7/8.8.7) with ESMTP id VAA02778
	for <hackers@FreeBSD.ORG>; Fri, 22 May 1998 21:56:43 GMT
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.8/8.8.6) id XAA02627;
	Fri, 22 May 1998 23:56:38 +0200 (MET DST)
Message-ID: <19980522235637.35026@follo.net>
Date: Fri, 22 May 1998 23:56:37 +0200
From: Eivind Eklund <eivind@yes.no>
To: hackers@FreeBSD.ORG
Subject: Kernel hackers Tricks & Tips
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At request, I start off this document - I'll also volunteer to
function as editor until it is in a suitable state to be put in the
handbook.


1. The kernel is large; it is convenient to be able to grep in it
   without it taking time corresponding to it's size.  To accomplish
   this, you can use 'glimpse' from the ports collection
   (textproc/glimpse).
   To build the indexes (assuming you have your kernel in /sys):
   % glimpseindex -b /sys/ 
                  ^^ large index - no option give you a tiny index
                  (2-3%), -o small (7-8%), -b large (20-30%)
   Afterwards, you just use
   % glimpse <regexp>
   to search for <regexp>.  Glimpse support a somewhat limited set of
   regexpen.

2. Sometimes you might want to do large-scale style-changes to the
   kernel (e.g, moving options to be 'new-style' instead of
   'old-style').  These are changes that should result in any change
   to the kernel, but how do you test that?  Simple - diff the object
   files from an old kernel against the object files from your a
   kernel with your changes in it.  However, don't become too scared
   if something turn up as changed - a few kernel files contain
   uses __LINE__ for printing debugging info; check for this first.

3. You can automatically find problems (potential bugs) in old source
   by running flexelint against it - flexelint is available from
   Gimpel software (http://www.gimpel.com/).  It is kind of pricey,
   but tend to pay back quickly if you're programming for a living.
   It e.g. allowed staticizing of the entire FreeBSD kernel in
   approximately two hours.  ("Just a satisfied customer" and all that
   stuff.)

4. If you are changing kernel APIs and wonder if your changes are
   breaking the LKMs, there is a simple test.  Compile the 'LKM'
   kernel, build the LKMs, and run 'make regress' in the src/lkm
   directory.

5. There exists a 'magic' way of making timing-related bugs static:
   Add full checking for the integrity of datastructures (invariants).
   If you have a weird bug involving timing-dependent corruption, add
   as full checks as you are able to any nearby data structures.  The
   bugs tend to suddenly become deterministic failures.  (This assume
   that you have some knowledge of the area of code you're changing).

Now, anybody else want to chip in?

Eivind.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message