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.

Several hours later and feeling several years older, I copied the provided Multia configuration (the file CANE) to another file. The NetBSD team provided these examples for very good reason, and if I was smart I would have used them in the first place.

In my case, trimming the kernel configuration file turned out to be very straightforward. I don't run MFS or NFS on this system, so they went. Since it's a new system, I didn't need compatibility with older versions of NetBSD. On a one-gig disk, I can't really play with OSF/1 compatibility, Linux compatibility, or any of NetBSD's other nifty emulation features. Whack, whack, whack.

The next part was quite familiar:

Don't forget to run "make depend"

Config doesn't give you any notice of where the kernel compilation directory is, but after a bit of poking I found it in ../compile/SCRAPYARD. Man config (8) would have told me that, but I didn't think of that until after I found it.

From there, it was fairly simple:

cd ../compile/SCRAPYARD
make depend && make && make install

The system churned. I went home. The next morning, I was looking at a nice long stream of successful compiles, followed by:

make: don't know how to make install. Stop

The NetBSD FAQ came in handy here. The kernel install procedure turns out to be frightfully complicated:

cp /netbsd /netbsd.old
cp netbsd /netbsd

Just like FreeBSD, you don't need to update any loaders or write new boot blocks for your average kernel change.

I rebooted, crossing my fingers. To my surprise, the new kernel booted flawlessly. The generic kernel is 3,401,386 bytes. My custom kernel is 1,757,159 bytes. On a 32 meg machine, that's a big difference.

When the time comes to tweak this kernel further, man (4) options lists all available kernel options. Stripping the kernel is the easy part; tweaking it for maximum performance is where the real BSD administrators stand out.

(The author would like to thank NetBSD devotees David Brownlee, Andy Doran, Hubert Feyrer, and Richard Rauch for their pre-publication review of this article.)

Michael W. Lucas

Read more Big Scary Daemons columns.

Discuss this article in the Operating Systems Forum.

Return to the BSD DevCenter.


Copyright © 2017 O'Reilly Media, Inc.