Kexts are loadable bundles, and like all loadable bundles, they are loaded dynamically by another application. In the case of a kext, this application is the kernel itself. This has many implications for kexts, such as running in supervisor mode and the ability to load during early boot. Kexts have strict security and location requirements that you need to follow for your kext to work.
To understand the anatomy of a kext, you should have a basic understanding of bundles. For general information on the structure of a bundle, see Bundle Programming Guide.
In the simplest case, a kext bundle contains two components: an information property list and an executable. Along with these required components, a kext bundle may optionally include additional resources and plug-ins. Each of these components is described below.
A kext’s Info.plist file describes the kext’s contents. Because a kext can be loaded during early boot when limited processing is available, this file must be in XML format and cannot include comments. The following keys are of particular importance in a kext’s Info.plist file:
CFBundleIdentifier is used to locate a kext both on disk and in the kernel. Multiple kexts with a given identifier can exist on disk, but only one such kext can be loaded in the kernel at a time.
CFBundleVersion indicates the kext’s version. Kext version numbers follow a strict pattern (see “Info.plist Properties for Kernel Extensions”).
OSBundleLibraries lists the libraries (which are kexts themselves) that the kext links against.
IOKitPersonalities is used by an I/O Kit driver for automatically loading the driver when it is needed.
There are several more kext-specific Info.plist keys that allow you to further describe your kext. For a complete discussion of all kext Info.plist keys, including keys that refer to kernel-specific runtime facilities, see “Info.plist Properties for Kernel Extensions.”
This is your kext’s compiled, executable code. Your executable is responsible for defining entry points that allow the kernel to load and unload the kext. These entry points differ depending on the Xcode template you use when creating your kext. Table 1 describes the default differences between the two kext Xcode templates. This table is intended to illustrate only the most common use of each template; the kernel does not differentiate between kexts created with different templates, and it is possible to incorporate elements of both templates into a kext.
Generic kernel extension template | IOKit driver template | |
|---|---|---|
Programming language | Usually C | C++ |
Implementation | C functions registered as callbacks with relevant subsystems | Subclasses of one or more I/O Kit driver classes, such as |
Entry points | Start and stop functions with C linkage | C++ static constructors and destructors |
Loading behavior | Must be loaded explicitly | Loaded automatically by the I/O Kit when needed |
Unloading behavior | Must be unloaded explicitly | Unloaded automatically by the I/O Kit after a fixed interval when no longer needed |
Tutorial |
Kexts sometimes require additional resources, such as firmware for a device. If your kext requires a resource, put it in the Resources folder of your kext’s bundle. If you plan to localize your resources, keep in mind that kernel-space code does not detect localized resources. User-space code does detect localized resources in .lproj subfolders of the Resources folder, so if your resource is accessed only by user-space code, localization is straightforward.
In addition to general resources, kexts can contain plug-ins, including other kexts. If your kext uses a plug-in, put it in the PlugIns folder of your kext’s bundle. Make sure that plug-in kexts do not contain plug-in kexts of their own; only one level of plug-ins is detected in order to limit file system traversal during early boot.
Kexts execute in kernel space and run in supervisor mode; consequently, files and folders in a kext bundle must be owned by the root user and the wheel group. Files must have the permissions 0644, and folders must have the permissions 0755. A kext that fails to meet these requirements will not load into the kernel.
During development, to ensure that your kext has the proper ownership and permissions, create a copy of your kext as the root user.
% sudo cp -R MyKext.kext /tmp |
Password: |
This method requires creating a new copy of the kext every time you build it.
Mac OS X looks up a kext by its CFBundleIdentifier information property list key. Kexts located in /System/Library/Extensions, and the plug-in kexts of those kexts, are searched by default. You can perform a custom search to locate kexts in other folders, but this approach is not recommended. If your kext needs to be loaded during boot loading, it must be installed in /System/Library/Extensions for the operating system to locate it.
Last updated: 2010-03-19