Date: Fri, 22 May 1998 23:56:37 +0200 From: Eivind Eklund <eivind@yes.no> To: hackers@FreeBSD.ORG Subject: Kernel hackers Tricks & Tips Message-ID: <19980522235637.35026@follo.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980522235637.35026>