This section discusses several important differences between kernel modules and user programs.
The following characteristics of kernel modules highlight important differences between the execution of kernel modules and the execution of user programs:
Kernel modules have separate address space. A module runs in kernel space. An application runs in user space. System software is protected from user programs. Kernel space and user space have their own memory address spaces. For important information about address spaces, see User and Kernel Address Spaces on x86 and SPARC Machines.
Kernel modules have higher execution privilege. Code that runs in kernel space has greater privilege than code that runs in user space. Driver modules potentially have a much greater impact on the system than user programs. Test and debug your driver modules carefully and thoroughly to avoid adverse impact on the system. For more information, see Device Driver Testing Tips.
Kernel modules do not execute sequentially. A user program typically executes sequentially and performs a single task from beginning to end. A kernel module does not execute sequentially. A kernel module registers itself in order to serve future requests.
Kernel modules can be interrupted. More than one process can request your driver at the same time. An interrupt handler can request your driver at the same time that your driver is serving a system call. In a symmetric multiprocessor (SMP) system, your driver could be executing concurrently on more than one CPU.
Kernel modules must be preemptable. You cannot assume that your driver code is safe just because your driver code does not block. Design your driver assuming your driver might be preempted.
Kernel modules can share data. Different threads of an application program usually do not share data. By contrast, the data structures and routines that constitute a driver are shared by all threads that use the driver. Your driver must be able to handle contention issues that result from multiple requests. Design your driver data structures carefully to keep multiple threads of execution separate. Driver code must access shared data without corrupting the data. For more information, see Chapter 3, Multithreading, in Writing Device Drivers for Oracle Solaris 11.2 and Multithreaded Programming Guide .
The following characteristics of kernel modules highlight important differences between the structure of kernel modules and the structure of user programs:
Kernel modules do not define a main program. Kernel modules, including device drivers, have no main() routine. Instead, a kernel module is a collection of subroutines and data. A device driver is a kernel module that forms a software interface to an input/output (I/O) device. The subroutines in a device driver provide entry points to the device. The kernel uses a device number attribute to locate the open() routine and other routines of the correct device driver. See Device Drivers for more information on entry points. See Device Numbers for a description of device numbers.
Kernel modules are linked only to the kernel. Kernel modules do not link in the same libraries that user programs link in. The only functions a kernel module can call are functions that are exported by the kernel. If your driver references symbols that are not defined in the kernel, your driver will compile but will fail to load. Oracle Solaris OS driver modules should use prescribed DDI/DKI (Device Driver Interface, Driver-Kernel Interface) interfaces. When you use these standard interfaces you can upgrade to a new Oracle Solaris release or migrate to a new platform without recompiling your driver. For more information on the DDI, seeDDI/DKI Interfaces in Writing Device Drivers for Oracle Solaris 11.2 . Kernel modules can depend on other kernel modules by using the –N option during link editing. See the ld(1) man page for more information.
Kernel modules use different header files. Kernel modules require a different set of header files than user programs require. The required header files are listed in the man page for each function. See man pages section 9: DDI and DKI Kernel Functions for DDI/DKI functions, man pages section 9: DDI and DKI Driver Entry Points for entry points, and man pages section 9: DDI and DKI Properties and Data Structures for structures. Kernel modules can include header files that are shared by user programs if the user and kernel interfaces within such shared header files are defined conditionally using the _KERNEL macro.
Kernel modules should avoid global variables. Avoiding global variables in kernel modules is even more important than avoiding global variables in user programs. As much as possible, declare symbols as static. When you must use global symbols, give them a prefix that is unique within the kernel. Using this prefix for private symbols within the module also is a good practice.
Kernel modules can be customized for hardware. Kernel modules can dedicate process registers to specific roles. Kernel code can be optimized for a specific processor.
Kernel modules can be dynamically loaded. The collection of subroutines and data that constitute a device driver can be compiled into a single loadable module of object code. This loadable module can then be statically or dynamically linked into the kernel and unlinked from the kernel. You can add functionality to the kernel while the system is up and running. You can test new versions of your driver without rebooting your system.
Data transfer between a device and the system typically is slower than data transfer within the CPU. Therefore, a driver typically suspends execution of the calling thread until the data transfer is complete. While the thread that called the driver is suspended, the CPU is free to execute other threads. When the data transfer is complete, the device sends an interrupt. The driver handles the interrupt that the driver receives from the device. The driver then tells the CPU to resume execution of the calling thread. See Chapter 8, Interrupt Handlers, in Writing Device Drivers for Oracle Solaris 11.2 .
Drivers must work with user process (virtual) addresses, system (kernel) addresses, and I/O bus addresses. Drivers sometimes copy data from one address space to another address space and sometimes just manipulate address-mapping tables. See Bus Architectures in Writing Device Drivers for Oracle Solaris 11.2 .