BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Big Scary Daemons

NetBSD for the FreeBSD User: Building a NetBSD kernel


Building a kernel is considered a rite of passage in the open-source Unix world. What nobody mentions, though, is that each new Unix you encounter has its own tricks and methods. What's normal behavior for one Unix can be strange and unusual for another. In short, a Unix administrator gets to have one rite of passage after another. Don't you feel lucky?

Having said that, building a NetBSD kernel isn't that different from building a FreeBSD kernel. The bumps and gotchas are just enough to keep you on your toes, not enough to actually stop you.

To build a kernel, you need the system sources and the comp set. My install didn't put them on my system; various NetBSD users have assured me that system sources are installed by default, so I'm willing to assume pilot error. Check under /usr/src/sys; if you have anything there, you either have the kernel sources or you're sloppy about where you store your MP3s.

Installing the kernel source is fairly simple; you can either use anonymous CVS, or just grab the appropriate tarball. We'll look at anonymous CVS in another article, when I decide to upgrade this beast. Go to Look for the directory for your version -- in my case, NetBSD-1.4.2. Under source/sets, you'll find syssrc.tgz. Download it, and extract it under / -- for example:

cp syssrc.tgz /syssrc.tgz
cd /
tar -xzvf syssrc.tgz

Depending on your system, this might take a while. On my Multia I started the process, raided the fridge, and chatted with my boss about why our the NT servers are so bloody unreliable. Just as I was considering roasting lunch over the Multia's fan exhaust, it finished.

The syssrc set contains the kernel sources for all the platforms NetBSD supports. That's a lot of stuff you'll never need. The platform-specific files are actually quite small, however, and not really much overhead compared to the total size of the kernel source.

Here I ran into my first problem; the Alpha architecture, or rather the lack of one. Alphas come in several different architectures, with different busses and designs. Those of you who have only worked on x86 systems haven't seen anything like it. Imagine that a "Pentium" system not only had different types of motherboards, but that each motherboard required specific drivers and handling. That's what an Alpha is like.

The NetBSD team is a jump ahead of things there; if you look under /usr/src/sys/arch/alpha/conf, you'll see several sample kernel configuration files, one for each of the main Alpha architectures. (Other architectures have similar files, if needed.)

I decided to make my own configuration by trimming down GENERIC, which is my standard FreeBSD practice. Much like FreeBSD, the command

grep ' at ' /var/run/dmesg.boot

gave me a list of everything in my system. I thought it would be a simple matter of gutting GENERIC.

This turned out to be a mistake, at least on the Alpha.

Unless you're familiar with Alpha hardware, trimming out what you don't want is a real pain. The GENERIC kernel configuration includes, as you might expect, every piece of equipment needed to get any type of Alpha up and on the net. With the wide variety of busses and architectures available for the Alpha, it's easy to leave excess stuff in. Unless you know what's inside your box, it's easy to goof. For example, if you include a device without the matching bus, config chokes with:

SCRAPYARD:121: scc0 at ioasic? is orphaned
 (nothing matching ioasic? declared)
*** Stop.

I don't know what the ioasic bus is, but I don't have one.

This isn't a problem on a more standardized architecture, such as the i386.

Pages: 1, 2

Next Pagearrow

Sponsored by: