Should You Program in the Kernel?
If you are thinking of writing code for the kernel environment,think carefully. Programming in the kernel can be a difficult anddangerous task. And often there is a way to accomplish what you want todo without touching the kernel.
Software that resides in the kernel tends to be expensive. Kernelcode is “wired” into physical memory and thus cannot be paged out bythe virtual memory system. As more code is put into the kernel, lessphysical memory is available to user-space processes. Consequently,paging activity will probably intensify, thereby degrading systemperformance.
Kernel code is also inherently destabilizing, much more so thanapplication code. The kernel environment is a single process, and thismeans that there is no memory protection between your extension ordriver and anything else in the kernel. Access memory in the wrongplace and–boom– the entire system can grind to a halt, a victim of akernel panic. Moreover, because kernel code usually provides servicesto numerous user-space clients, any inefficiencies in the code can bepropagated to those clients, thereby affecting the system globally.
Finally, kernel software is a real pain to write. There aresubtleties to grapple with unknown in the realm of applicationdevelopment. And because the tools for kernel development are in anearly stage of maturity, bugs in kernel code are harder to find than inuser-space software.
With all this in mind, the message is clear. It is in everyone’sbest interest to put as little code as possible into the kernel. Andany code that ends up in the kernel should be honed and rigorouslytested.
When Code Should Reside In the Kernel
A handful of situations warrant loading a driver or extension into the kernel environment:
- The software is used by the operating system itself.
- Multiple user-space programs will frequently use the software.
- The software needs to respond directly to primary interrupts (those delivered by the CPU’s interrupt controller).
If the software you are writing does not match any of thesecriteria, it probably doesn’t belong in the kernel. If your software isa driver for a disk, a network controller, or a keyboard, it shouldreside in the kernel. If it is an extension to the file system, itshould live in the kernel. If, on the other hand, it is used only nowand then by a single user-space program, it should be loaded by theprogram and reside within it. Drivers for printers and scanners fallinto this latter category.
Alternatives to Kernel-Resident Code
Apple provides a number of technologies that might let you accomplish what you want to do andstay out of the kernel. First are the higher-level APIs that give yousome hardware-level access. For example, the CFNetwork and POSIXnetworking APIs are a powerful resource for many networkingcapabilities and Core Graphics (Quartz) enables you to do some fairlylow-level things with the graphics subsystem.
Second, and just as important, is the “device interface” technologyof the I/O Kit framework. Using a plug-in architecture, this technologymakes it possible for your application to interact with the kernel toaccess most hardware. In addition, you can–with a little help from theI/O Kit–use POSIX APIs to access serial, storage, or network devices.
e documents special to each particular type of driver or extension.