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.