Creating a Custom Kernel Configuration File

Here's where you actually begin the process of creating a new kernel. Remember that you don't want to modify the GENERIC file itself; it gets updated with the system sources every time you synchronize or upgrade. Therefore, to make sure your changes don't get overwritten, make a copy of GENERIC to use as your custom kernel config. The name for the copy should be a single word in all caps, according to tradition. The custom kernel for this example is called CUSTOM:

# cd /usr/src/sys/i386/conf # cp GENERIC CUSTOM

You can now modify the CUSTOM file all you like. The first thing you should do is go through it and change the identification of the kernel (the ident line) from GENERIC to CUSTOM (or whatever name you chose). You also should remove redundant entries for cpu and, if necessary, modify the default value of maxusers by adding a line for it (see the following note). Here is a block from a customized kernel config on a Pentium IVclass machine operating as a high-profile server:

machine      i386 cpu          I686_CPU ident        CUSTOM maxusers     64

Note

Don't be fooled by the maxusers setting: It doesn't actually limit the number of current users or logins the system will support. (That limit is controlled by the device pty num line.) What maxusers does is much more subtle: A number of internal table sizes are derived from it, such as the maximum number of processes allowed (16 times the maxusers setting, plus 20) and several others. Set maxusers to approximately what you expect the average number of users to be, but don't set it lower than 4 (if you do, you'll run out of processes quicker than you expect).

You can now start customizing the options and devices. Refer to the hardware-specific and hardware-independent NOTES files to keep yourself informed about what you're modifying, and keep your other window with the dmesg output open. Don't delete anything from the config file that dmesg says the kernel found! It's in fact a good idea not to actually delete any lines from the file. Instead, just comment them out by putting a hash mark (#) at the front of each line.

If you have any doubt about whether to disable a line that's in GENERIC, don't disable it. GENERIC definitely contains a lot of items that aren't needed on every system, but it's better to err on the side of caution when it comes to kernels, especially if you're making these changes on a production server.