Deciding Whether to Create a Kernel Extension
There are often safer, easier alternatives to creating a kernel extension (kext). It is important to make sure creating a kext is absolutely necessary before doing so.
Make Sure Your Code Needs to Run in Kernel Space
The only reason to write a kext instead of a user-level application or plug-in is to use functionality that is unique to kernel space. The following cases require kernel-resident code:
The primary client of your code resides in the kernel. File-system and networking device drivers fall into this category.
Your code needs to handle a primary interrupt (a CPU interrupt generated by hardware). Many device drivers fall into this category: network controllers, graphics drivers, audio drivers, and so on. A USB or FireWire device driver does not require a kext unless its client resides in the kernel.
A large number of applications require a resource that your code provides.
If your code does not meet any of the above criteria, do not write a kext. Use one of the following user-level solutions instead:
If you are developing a USB or FireWire device driver, I/O Kit provides an interface for communicating with USB and FireWire devices from user space. See USB Device Interface Guide and FireWire Device Interface Guide.
If you are developing a persistent background application that does not require kernel permissions, write a daemon. See Daemons and Services Programming Guide.
Proceed with Caution
If you have determined that a kext is the proper solution for your issue, keep in mind that developing a kext is riskier and more difficult than developing a user-level application for many reasons, including the following:
Kexts reduce the memory available to user programs, because kernel-space code requires wired memory (it cannot be paged out).
The kernel runtime environment has many more restrictions than the user space runtime environment, and they must be followed carefully to avoid errors. See Kernel Programming Guide for details.
Programming errors in a kext are far more severe than bugs in user-level code. Kernel-space code runs in supervisor mode, and it has no protection from memory errors. Consequently, a memory access error in a kext causes a kernel panic, which crashes the operating system.
Debugging kexts is more difficult than debugging user-level programs, because it requires two machines and additional steps to set up a debug session.
For security reasons, some customers restrict the use of third-party kexts.